Random Authentication Node Selection Mechanism in Block Network for Meta-Mobility Service Data Reliability

1. Introduction

Unlike internal combustion engine vehicles, today’s vehicles are getting more electric and this means increasing electrification of various devices that are controlling driving by subjecting many vehicles parts to control by sensors [1,2]. On top of this, advances in IoT communication technology helps personally-owned bicycles and kick-boards be remote controlled and protected against theft, which in turn, is an accelerator for shared services. The mobility sector is currently focusing on building shared mobility while also conducting research in the area of meta-mobility, which combines virtual environments of metaverses with mobile services, as the next generation of mobility. Meta-mobility aims to provide users with immersive experiences through various mobile services. In simple terms, research is being conducted on meta-mobility, which combines various mobile services and immersive experiences in the field, while emphasizing the establishment of shared mobility. The mobility services are being offered as subscription-based services, and the business models are evolving to generate sustainable and stable revenue by integrating metaverses [3,4,5].

At present, subscription services are limited only to such functions as autonomous driving and smart phone vehicle control system to improve user convenience. As mobility services get more intelligent there is greater need to protect numerous data created along the way. At the same time, electric vehicle control as opposed to the analogous vehicle control that is independent raises the risk of a vehicle owner hijacked of driving power by a third party infiltrating from a foreign network, which could result in an accident [6,7,8]. Therefore, future mobility services require means to securely protect data in order to not only provide simple network communication but also deliver stable virtual environments to users [9].

Block chain is apparently an attractive solution in that it guarantees integrity of mobility data and helps contracts to be implemented on a real time basis. Yet, there are many challenges in applying it in a limited mobility environment. It guarantees transparent transactions and reinforces integrity of block data as blocks increase, which makes it a good choice in many areas [10,11,12]. In particular, PoW, which does not restrict participants, faces more issues to be addressed in order to acquire compensation for creating transaction blocks. Mobility environment, in general, does not require high performance and shared mobility such as bicycles and kick-boards should consider low performance and energy efficiency since it is based on IoT environment. This requires PoW to perform computation in order to continuously get hash value to compete for block creation. This also suggests limitations in applying in shared mobility environment in that client-to-client communication has to be made [13,14,15,16].

Compared to PoW, which exhausts resources for hash computation to create blocks, PoS that acquires block creation authority corresponding to one’s share can substitute resources consumed for hash computation by proving its own share. This enables application with lower performance level. However, the fact it acquires authority as per share and subsequent compensation means it is prone to fixation [17,18].

Mechanism proposed in this thesis provides tokens to create blocks by selecting random nodes to reinforce data integrity in a limited scope whereby share from block creation does not affect mobility service in itself. Also, the use of encrypted tokens in the course of sending them decodes encrypted tokens only in specific nodes ensures communication without disclosing selected nodes in network.

2. Related Studies

2.1. Shared Mobility Service Network

There are many network standards that include NB-IoT(NarrowBand-Internet of Things), LoRa(Long Range) and eMTC(enhanced Machine-Type Communication) for application to mobility services. In particular, low power, low performance and higher energy efficiency are in demand for use in such limited performance as IoT. IoT network standard focuses more on energy efficiency and data transmission distance than on speed itself since it has to be applied in the limited IoT environment [19,20].

LoRa is a wireless communication technology for low power, long-distance communication. It derives from CSS(Chirp Spead Spectrum) technology. Its low transmission means it is applicable to IoT that sends small-sized data and transmission speed is 290bps in 14km coverage and 5470bps in 2km coverage. It consumes less battery since it transmits data and maintains slip with consistent time interval [21].

NB-IoT is the standard low power, broad communication technology established by 3GPP(3rdGenerationPartnershipProject) mobile communication standardization organization. With a narrow bandwidth of 180kHz, it supports 250kbps in data transmission speed and broad service beyond10km. It is suitable for fixed smart service since it does not support mobility. It is applicable to an IoT environment characterized by less frequent data use, low power consumption and low mobility. It is also ideal for metering sensors like water, gas, electricity, temperature as well as smart lights, location tracing devices that are located in remote areas [22].

eMTC, which is also known as LTE cat M1, was standardized by 3GPP’s Release 13. It provides up to 1Mbps in data transmission speed at 1.4MHz bandwidth. It also provides VoLTE(Voice over Long Term Evolution). Its high data transmission speed makes it a good application for technologies that require heavy data such as tracking mobile objects or real time services [23].

As shown in [Table 1], which compares IoT communication technologies, environment with less mobility does not require real-time processing from LoRa or NB-IoT technologies. Rather, they are applied to environments with smaller data transmission volume. In mobility services, on the other hand, data has to be processed real time and mobility has to be guaranteed, too. In mobility services that require mobility and real-time processing such as kick-boards in Korea, eMTC is applied.

2.2. Blockchain Consensus Mechanism

Block chain consensus mechanisms include PoW(Proof of Work), PoS(Proof of Stake) and DPoS(Delegated Proof of Stake), etc.

PoW, which is the most well-known mechanism, gives block creation authority to the node that used the largest amount of resources to creating block chain’s block. The process of substituting nonce value on a repeated basis to find hash value below target value, thereby solve largest number of problems and have the authority to create blocks is called mining [24,25,26]. Bit coin, which is the most popular example of PoW, is huge in size and its network is protected from attack by 51% capable of exercising block’s forgery by participating node 51%, which is one of the weaknesses of block chain. This is because the economic value required to acquire node’s 51% computing power to prevent data forgery is exponentially high and therefore poor in efficiency [27]. Difficulty of mining is set in a way to produce a certain interval as per computation level of nodes taking part in the mining process, which subsequently, aggravated competition for mining using high-specification equipment. This, in turn, made mining more challenging and mining equipment that is higher in performance in need. Growing necessity of high-performance computing equipment is consuming more electric power and causing too much waste of energy [28,29].

PoS is an algorithm that grants decision-making authority to node based on shares. It takes parts in creating blocks by proving its shares to the block and therefore does not demand resources consumed in the course of mining, which is unlike PoW that competes to acquire compensation [30,31]. As such, it consumes less energy and all nodes that has shares take part in decision-making since block’s updating authority is matched by shares. One key example operating in PoS is ethereum. Its consensus mechanism was based on PoW at first but has since converted to PoS. Thanks to this conversion, it not only consumes less electricity in mining but also mitigates environmental issues such as heat generated during mining. These changes are not without downsides. Compensation in PoS method makes distribution based on shares. This means higher compensation to nodes with higher shares, which subsequently has bigger impact on the network and issues associated with coins concentrated in specific nodes [32,33].

DPoS method is an algorithm whereby nodes can exercise their voting rights as per shares and engages in decision-making via the selected proxy. Since it appoints a proxy that will make decisions on behalf by acquiring voting rights per share transaction approval by a few representatives can accelerate processing speed relative to PoS solution where all nodes take part [34]. However, that blocks are created only by a few selected proxies is a far departure from meeting the objective of block chain, which is decentralization. Another downside is that participants with less shares are selected as proxy. Those with many shares in DPoS environment do not want to see their shares undermined and this can promote participants’ reliability. On the contrary, such participants are at higher risk of undermining shares and this could adversely impact the block chain environment [35,36].

2.3. Related Research Trend

Various studies on mobility services leveraging block chain are in progress in sync with advances in shared mobility services. In particular, there are many studies underway to share vehicles and to apply in low-performance environment without limiting the scope of research to apply block chain in mobility environments based on IoT.

In one research, Sophia examined shared mobility environment based on IoT and particularly focused on cases applying to vehicle sharing and vehicle lease environment. The research proposed architecture of a platform based on IoT and block chain to promote shared mobility by combining vehicle sharing and lease and realized a platform that simplifies sharing and lease procedures. In a research by Madhusudan [37], it was mentioned that intelligent vehicles are recording innovative growth but there are a lot of security vulnerabilities at the same time and challenges in safely sharing data with traditional way of security protection. As a solution, the research suggested determining security elements that are required for data sharing and sharing intelligent vehicle data. In another one by Madhusudan [38], he mentioned that intelligent vehicles perform vehicle-to-object communication based on the Internet and such communication environment brings with it a wide variety of security vulnerabilities. Major issues witnessed in intelligent vehicle communication include reception in communication channels, data reliability, accuracy and security, and studies to build reliable intelligent transportation system by applying block chain as solutions were carried out.

Researches on shared mobility environment are not limited to vehicles. In fact, researches are being made in various areas like bicycle sharing services. Hanyue set leakage of users’ personal information by shared bicycles and property damage as key issues in his research [39]. As a solution to this, he proposed bicycle sharing system based on block chain service platform and C2C(consumer-to-consumer) shared operation method to address limitations of the existing centralized method. Daozhi’s research [40] looked into a system that taps into smart contract to prevent issues arising from companies declining to return user deposit when they discontinue bicycle sharing service in the course of the rapid growth of the platform.

3. Proposal of Block Network Random Authentication Node Selection Mechanism

Objective of this thesis is to record information such as user information, mobility device information and payment information in shared mobility environment in block networks. General mobility environment is defined by equipment put to use for services by companies. Hence, block networks in mobility environment do not need to register countless number of users in the open network. Block networks, therefore, form a private block chain structure accessible only by certified users. Private block chains, however, can be modulated by a few upper nodes dominated in the process of forming transactions since authority over user participation and block creation is handled by an upper body. Hence, upper nodes go through authentication process to access block networks in this thesis and block creation authority is performed by nodes in the block network. Block creation authority in the block network is performed by tokens, which are authentication means to acquire authority to create blocks. As a way to transmit random nodes on the block network after blocks are creation it averts monopoly.

[Figure 1] is the general concept of the mechanism proposed. Mobility device is a concept covering kick-boards, bicycles and intelligent vehicles that are part of the shared network. Devices are managed by shared service provider’s server and only registered devices are joined as members of the block network. Each device becomes a node in the network. Number of tokens remains consistent as per consensus by groups that provide the service. The initial token is issued by service provider groups and tokens are transmitted after selecting random nodes in the block network. Node aggregates that received the token build consensus network to create blocks among nodes that have tokens and create blocks. Nodes that created blocks select random nodes in the block network and encrypt token information and own information with corresponding node’s public key for transmission to the entire network. Nodes that have been deciphered with private key acquire the authority to create next block.

Block network random authentication node selection mechanism is divided into registration module that registered mobility devices on server, token issue module that creates token based on service provider’s consensus and provides to block network, mobility transaction module that performs consensus process to process mobility transaction and token transmission module that transmits tokens to other nodes.

3.1. Mobility Device Registration Module

In mobility device registration module, mobility service provider performs device registration process via server, which handles provider’s mobility device. In other words, block network’s node is limited only to mobility devices authenticated by service provider. Information to recognize mobility device is required to register mobility device. [Table 2] is a list of data needed for the mobility device to be recognized in the proposed mechanism.

Authentication servers in block network identify devices by utilizing identification number created by service provider and MAD address of IoT communication device included in mobility device. Service provider creates device identification public information(DPI), which converted identification number and MAC address to hash value, and transmits public device consensus data(DPA) including service type, service provider and registration date to authentication server taking part in building mobility block network. [Formula 1] shows the process of creating hash value after performing hash computation of the two identification information to identify devices themselves. This is to keep too much information from being provided meaninglessly to other server that does not look for direct identification information. [Formula 2] means data structure to share information of mobility device to utilize nodes in other server.

$$D_{PI}=Hash(N_{ID}+A_M)$$

(1)

$$D_{PA}=str(D_{PI}+S_C+S_{PV}+D)$$

(2)

Authentication servers in block network that have public device consensus data check public device consensus data received and transmit number of mobility devices that have been requested to add in the block network, registration requested date and information of service provider to all authentication servers taking part in the block network. When identical information is shared across servers node creation authority whose number is the same as the aggregate of public device consensus data is added to the authentication server in the block network to which public device consensus data is transmitted. Authorized authentication server sets each mobility device as node and builds block network. [Figure 2] is the process of registering mobility devices into new nodes through consensus among authentication servers to have mobility devices participate in block network in the mobility device registration module.

3.2. Token Issue Module

Token issue module is a module that issues token including authentication information and allows node that has a token on block network to create a block. Token initially issued is created based on consensus among authentication servers participating in block network. It includes matching key to grant authority on token issuance.

[Figure 3] is the configuration of token-created node transmitting token to random node belonging to block network. Token transmission requires two times of encryption. In the first one, the node, which created the token, encrypts token with its own secret key to inform that it has created a token. In the second one, encryption takes place with the target node’s public key to make sure token information is not caught by node other than the target node that needs to have the token. As such, node without a token can confirm entire hash value, which is the correct answer to verify authority of the block, and question proving block creation authority, which is the question designed to verify authority. However, secret key on block creation is needed to solve question on proving block creation authority and hence verification cannot be completed. Node with a token can verify block with block creating secret key. [Table 3] shows information included in token.

Token group matching key utilizes identification information of previous token group. When issuing token for the first time, information of token creation server that is in consensus with token group matching key is used.

[Figure 4] is the process of how a block creates tokens. Token that is initially issued includes matching key to build network of nodes that have tokens, secret key to be used as verification means to acquire authority to create next block, identification information of server that creates token, identification information of node that will receive token and lastly value that performed has computation for identification information of secret key and server, token order information and node identification. [Formula 4] shows the process of computing hash value for all token values.

$$S{K}_{TG}=Hash\left({\sum }_{i=0}^{n}TokenID\left[i\right]\right)$$

(3)

$$H_{TD}=Hash(S{K}_{TG}+P{B}_{BC}+C{I}_{TC}+C{I}_{TN}+R_T)$$

(4)

When block creation secret key included in token is (d, N), block creation public key(PUBC) is (e, N) then token that has not been encrypted is configured as shown in [Formula 5].

$$Token cert=(Encryption Ke{y}_{TG}, Private Key\left(d, N\right), C{I}_{TC}, C{I}_{TN},R_T,H_{TD})$$

(5)

[Figure 5] shows the formula process to broadcast token encrypted by block creation node to the block network.

Token that has been created uses public key(et, Nt) of the node set to receive token to perform token encryption as shown in [Formula 6].

$$Encryption Token={\left(Token cert\right)}^{et} mod N_t$$

(6)

Token is the created encrypted text. When it creates hash and block of encrypted token it encrypts with secret key of the node that creates token including block creation authority verification question(PBBC) to verify authority to create. [Formula 7] is the process to seek hash on the encrypted token and [Formula 8] is the process of how block creation authority is created by using the encrypted token.

$$T_{TO}=Hash(Encryption Token)$$

(7)

$$P{B}_{BC}=(H_{TO} mod N)$$

(8)

Token eventually broadcast to the block network is shown in [Formula 9].

$$Broadcast Token={\left(Encryption Token+H_{TO}+P{B}_{BC}\right)}^{db} mod N_b$$

(9)

[Figure 6] is the process of deciphering general nodes to which broadcast token has no authority over and tokens to node, which is the token’s subject.

Server that created token encrypts token by using public key of random nodes selected to transmit to random node in the block network and entire hash value and block creation authority verification question with its own secret key for broadcast to the block network. Node checks that it has been sent from the server by deciphering via server’s public key and acquires encrypted token, entire hash value and block creation authority verification question. [Formula 10] shows the process of deciphering with public key sent from block to decipher broadcast token.

$$\begin{gathered} Plaintext Broadcast={\left(Broadcast Token\right)}^{eb}mod N_b \\ =Encryption Token+H_{TO}+R{B}_{BC} \end{gathered}$$

(10)

Target node to which token should be sent uses its secret key to decipher token and acquire token group matching key in token and block creation secret key. [Formula 11] is the process of token target node deciphering encrypted token with its own secret key(dt, Nt) in order to decipher node.

$$\begin{gathered} Token={\left(Encryption Token\right)}^{dt}mod N_t \\ =(Encryption key(S{K}_{TG}, Pravate Key\left(d, N\right), C{I}_{CT}, C{I}_{TN}, R_T, H_{TD}) \end{gathered}$$

(11)

Node creates token group by using matching key and collects transaction to create block. Nodes then create block and perform verification with its secret key. Nodes that failed to have token use secret key included in block verification to decipher block creation authority verification questions and check if the results are identical with the entire hash value to confirm verification. Nodes that have created block afterwards create new tokens by selecting secret key created by node, which has matching key and token that can be identically used among token groups, and random node to which token will be sent.

3.3. Mobility Transaction Module

Mobility transaction module is a series of process of collecting transactions and providing mobility service to users. It performs consensus process between transaction’s data structure in the mobility node and transaction itself. Mobility transaction data is created by mobility device. It is executed when user information is forwarded to mobility device upon user request. Mobility device is composed of user information secured, additional time information, mobility device information and regional information, which serve as one single transaction. Mobility transaction data structure can be described in [Table 4].

Upon request for user by user mobility device fills out mobility transaction data including user information received upon request. The transaction is encrypted as mobility node’s secret key and broadcast to the block network. The broadcast transaction then performs verification via token node.

[Figure 7] is the execution process to verify mobility transaction. All transactions are collected by token node and blocks are created based on consensus between token nodes.

The collected transaction is collected by token node and hash computation is performed for each transaction to create hast list(LTH). [Formula 12] is the process whereby hash list is created.

$$L_{TH}={\sum }_{i=0}^{n}Hash\left(Transaction\left[i\right]\right)$$

(12)

The first token node creates transaction hash list(LTH), which is the result of executing hash computation for the transaction collected. Transaction hash list that has been created is encrypted as the public key(PUTN) of token node following in the next order and is encrypted as token group matching key for broadcast to block network. When public key is (enb, Nnb) and secret key is (dnb, Nnb) for node that will receive transaction hast list [Formula 13] broadcasts transaction hash list to the block network to show the process of deciphering token group to a certain node. [Formula 14] shows token group encryption when secret key of token group is a and SBox for encryption and matching table for deciphering is InvSBox.

$$Next Token Node Encryption=({\left(L_{TH}\right)}^{enb} mod N_{nb})$$

(13)

$$Token Group Encryption=a*SBox*({\left(L_{TH}\right)}^{enb} mod N_{nb})$$

(14)

The broadcast transaction list is deciphered first by token group’s matching key and thus is shared only within token group. Even within the group the transaction hash list as it is can be obtained only with a certain node’s secret key. [Formula 15] is the process of a certain selected node executing deciphering via token group matching key. [Formula 16] is the process of acquiring transaction hash list by using own secret key.

$$\begin{gathered} 1st Decryption=a*InvSBox*\left({\left(L_{TH}\right)}^{enb} mod N_{nb}\right) \\ ={\left(L_{TH}\right)}^{enb} mod N_{nb} \end{gathered}$$

(15)

$$\begin{gathered} 2st Decryption={\left(L_{TH}\right)}^{dnb} mod N_{nb} \\ =L_{TH} \end{gathered}$$

(16)

Token node compares broadcast transaction hash list with its own transaction hash list to perform verification with its own identification information for the same items. It then broadcasts transaction hash list verified to the next token node including verification result of transaction hash list. [Formula 17] is the process of executing verification by comparing transaction hash list with own transaction has list and performing renewal with verification result including its own identification information.

$$Transaction List=\left\{\begin{array}{c}Hash\left(Transaction\left[i\right]\right), C{I}_{TNx}, if\left)Hash\right(Transaction\left[i\right])\in L_{THx+1}\\ Hash\left(Transaction\left[i\right]\right), else\left)Hash\right(Transaction\left[i\right]){\notin L}_{THx+1}\end{array}\right.$$

(17)

The renewed transaction list repeats the process from [Formula 12] to [Formula 14] before sending to the next block.

[Figure 8] is the general consensus process of token nodes to perform transaction verification. Token node that has received verified transaction hash list of all token nodes creates transaction verification list(LTV) including transaction list verified by all token nodes and transaction’s hash verification list verified by more than half of nodes. It is then encrypted with token group matching key and broadcast to all networks. This is followed by request for verification and its propagation to the incoming node. Token node that has been requested compares it with its own transaction list and sends it to all token groups when there exists transactions with multiple verifications(TDV). Transactions not in the transaction list remove themselves in their own list and renew order as per the list before propagating request to perform verification to the node next in order. The first node requested for transaction verification by Nth token node verifies its own block with the secret key in the authentication token and broadcasts to the node next in order. Token nodes that received block in the consecutive order then verify with its own secret key. Nth token node broadcasts to the block network to let block verification by all nodes when number of verifies is more than half of the entire token group.

3.4. Token Transmission Module

Token transmission module’s role is to create block, issue new token and transmit them to the next block. Token group node uses token’s block creation secret key to verify block verification in order to create block. It then issues and attaches token from among the next node that has been randomly selected. The newly-issued token creates token group matching key, block creation secret key, token creation server identification information, target node identification information and token hash identical with the authentication token created by server.

Token group matching key creates one matching key via token node group and each token node uses matching key created to its own token group matching key, which is then used as the matching key for the next node to form token group. Since block creation public key pair is the solution to prove itself to create block each token node creates independent public key pair with different contents. Token creation server identification information enters identification information of node renewing token and used to prove node that has been created by random node receiving token. Target node identification information refers to identification information of random node and token hash adds hash value that performed computation towards token just like the server. In short, token node that created a block itself works as a single CA(Certificate Authority) and plays the role of a one-off certifying agency for token.

[Figure 9] is token verification process. Random node that acquired token information confirms node that created token via token creation server identification information and encrypts its own identification information authentication token’s token hash with its public key for propagation(broadcasting). By using its secret key, verification node identifies authentication request by the encrypted random node and encrypts identification information of verification node and verification findings with random node public key for broadcast to the block network. Random node uses token as per verification results and creates token node group.

Token that has been created perform encoding with the public key of randomly selected node to prevent token details being restored by a node other than the target node. It then performs encoding with secret key of node that creates token to have token issuing entity be verified on the block network. The encrypted token is then broadcast to the entire block network. Block network nodes that receive encrypted tokens utilizer public key to get encrypted token information, all hash values and block creation authority verification questions, and uses its own secret key to acquire token information. When token information is restored by its own secret key it uses token group matching key to create token node group and token node creates block by verifying transactions.

4. Comparative Analysis with Existing Methodology

This thesis is proposing to select node with block creation authority on the block network based on random token and mechanism for processing mobility transactions. The process of consensus on block creation by using block creation authority requires comparative analysis with the consensus mechanism. The most common method for consensus mechanism is PoW and PoS while DPoS and PoA are also available.

In PoW consensus mechanism, which is the most known method, node computes hash value by substituting nonce value, which grows by one, to solve the question once node that created block broadcasts questions to all nodes. Result of the computed hash has to look for a hash that is smaller than the question and node that found the most number of values acquire the authority to create block and compensation by proving that it provided a lot of resources to the block network. Since block creation authority is gained by solving many questions it is suitable for decentralization since all nodes have the authority to create blocks but more competition associated with problem-solving wastes too much energy. As such, it is not an ideal choice for network based on low-performance IoT environment.

PoS consensus mechanism prevent inefficient energy consumption arising from intensifying competition by PoW consensus mechanism. It is also used to prevent monopoly by certain nodes that provide most amount of resources. What is used to prove block in PoS method is shares held by nodes not computing power by high performance devices to solve problems. Random verifier is selected to create block in PoS and the chances of being selected go up depending on how many tokens can be put up for stakes for block creation. Although it is a random selection it indicates that higher token stakes raises the chance for block creation. In short, the more the stakes by a node, the higher the chances of winning block creation authority. New nodes face higher entry barrier since they have less stakes than the existing ones, which could cause issues around fixation of block creation nodes.

DPoS consensus mechanism is one proposed to address the limitations of certain nodes monopolizing block creation authority by the stakes in PoS method. In DPoS method, which selects proxy to create block, each block selects proxy as per its own stakes. Its processing speed is fast since only a few selected proxy nodes verify transaction records. This isn’t without downsides. Two nodes with many stakes vote against each other and take a fixated form in order to stay qualified as block creation proxy.

Random token-based selection method proposed in this thesis allows only nodes that have token to take part in the group for block creation and creates consensus blocks in the token group network. As for nodes authorized to create block random nodes on the block network are selected and therefore all nodes have a chance to take part in block creation. Also, it does not require high performance since there does not need a computation process to acquire block creation authority. However, nodes authorized to create blocks maintain a consistent number and there is a risk of block forgery/counterfeit if more than half of selected nodes have malign intentions. Also, an issue of redundancy where more than two token nodes can set one single node into the next token node exists.

[Table 5] shows the difference in the consensus between the existing consensus mechanism and proposed mechanism. PoW needs to perform the biggest workload for block creation authority. In PoS node with biggest stakes has higher chance of acquiring block creation authority. In DPoS, stakes may be the key role in participating in block creation but it is different in that stakes are used to select proxy. The proposed mechanism utilizes token broadcast to the randomly-selected node in selecting proxy. High-performance mining is required only in PoW and not in PoS, DPoS and the proposed mechanism. Node itself is the verifier in PoW and PoS in that key node is selected to create block while key node in DPoS and the proposed mechanism is determined by vote based on each stake and random selection. PoW proof can be executed anonymously but node information is required for PoS and DPoS when selecting stakes or proxy. In the proposed mechanism token group matching key is used to let node with token only take part in the network. As such, node without token cannot gain token group information.