B-Tor: Anonymous communication system based on consortium blockchain

The rapid development of the Internet has led to the increasingly prominent feature of openness and transparency of user information. Tor, which is used to protect personal privacy, is one of the most widely used anonymous communication systems with the largest number of users. However, there are many problems with Tor, such as: illegal transactions in the dark network disturbing social security, high communication delays, and security problems such as vulnerability to DOS attacks, man-in-the-middle attacks, and censorship attacks. In this paper, we design and implement a new anonymous communication system B-Tor based on the original Tor architecture model combined with the mainstream consortium blockchain architecture Fabric, which can trace illegal transactions by using the traceability feature of blockchain and group signature algorithm. The consensus algorithm mechanism in blockchain is utilized to improve the communication efficiency and increase the throughput of the system. The system utilizes the decentralized feature of blockchain to solve the security problem of Tor mentioned above. The system performance evaluation and security evaluation are given in this paper. The experiments show that the communication delay of B-Tor anonymous communication system is low, and in the 600s user loop test, the system successfully receives the consensus file 790629 times with 98% success rate, the highest throughput is 1352.8 TPS, and the average delay is 0.1s. It is verified through the experiments that the system can be affected less during DOS attacks and can recover the state quickly.

AlphaBay and other online black markets. At the same time, it has also become a shelter for illegal transactions such as WannaCry ransom transactions and BitCoin money laundering transactions. At present, there is no complete and reasonable method for anonymous communication and darknet governance.
Tor (the second-generation onion route) is a widely used anonymous communication system. Its core "onion routing" was proposed by the US Naval Research Laboratory in the 1990s. The Tor system is based on a multi-hop proxy mechanism to protect the anonymity of users [12].
2 Background and related work 2.1 Anonymous communication system Tor The Tor system is mainly composed of a large number of distributed relay nodes. As shown in Figure 1, the overall system is mainly divided into the following five parts [13]: 1) Client (OP): a local program running on the user's operating system, providing anonymous proxy services for users. 2) Directory Server (DS). There are 10 worldwide. The function is to collect and organize node information in the network, generate consensus files according to internal algorithms, actively detect the reachability of nodes, update consensus files according to reachability, and allow clients to access and obtain consensus files, to complete node selection. and link establishment. 3) The Onion Router (OR). Data relay nodes in the Tor anonymous network. Tor's default anonymous link consists of three ORs, namely the entry node (Entry), the intermediate node (Middle), and the exit node (Exit). 4) Hide the server. Provides TCP application services such as Web and IRC. The hidden server is protected by Tor anonymity, and a Tor client must be used to be able to access its TCP application services. 5) Hide service directory server. The hidden service directory server stores and provides the client with node information such as the introduction point (IPO) and public key of the hidden server.

Blockchain technology
Most of the network systems in the traditional mode adopt the B/S architecture or the C/S architecture. The common feature of these architectures is that a centralized server is required. Each user needs to interact with the central server, including uploading and downloading data. However, in the process of data storage and transmission, the centralized management system has security and trust issues, and the vulnerability of the central server will also affect the use of users across the network. If the central server is paralyzed, it will affect the use of the entire network. Blockchain technology originated from a peer-to-peer cash transaction system proposed by Satoshi Nakamoto in 2008 [14]. Blockchain technology integrates various security mechanisms such as P2P network, cryptographic algorithm, consensus mechanism, link structure, etc., and realizes a decentralized system that ensures the credibility of the entire network.
A blockchain can be defined as an immutable ledger that records transactions and maintains a mutually distrusting distributed network. Each peer has a copy of the ledger. Peers perform a consensus protocol to validate transactions, group them into blocks, and build hash chains over the blocks. This process forms a ledger by ordering transactions, which is required for consistency. Blockchain has appeared in many applications such as Bitcoin, Ethereum, Hyperledger Fabric, etc., and is widely regarded as a promising technology for running trusted transactions in the digital world [15].

Attacks on Tor
At present, there are many kinds of attacks on Tor. Cambiaso E et al. classified various attack methods against Tor in 2019, attacking the client, attacking the server, and attacking the overall network [16]. Many researchers have shown that the Tor system has the following vulnerabilities.
DoS attack: Tor community developer Rob Jansen et al. proposed a sniper attack in 2014, an extremely low-cost and extremely destructive denial-ofserver attack [17]. At the same time, in 2019, it was explained that Tor faced DoS attacks and experimentally quantified the cost of each attack and its impact on Tor performance [18]. Mane Y D et al proposed an efficient technique for detecting Tor server DDoS attacks in 2020 [19]. In 2021, Rui Wang et al. experimentally demonstrated the effectiveness of DoS attacks and discussed the defense strategies for this attack [20].

Fig. 2: Tor attack location
Traffic identification attack: By capturing encrypted data traffic, preprocessing the data traffic, extracting traffic features from it, and finally using machine learning algorithms to select features and make classification predictions. Basyoni L conducted a traffic analysis attack on Tor from an attacker's perspective in 2020 and stated that this attack applies to the vast majority of Tor scenarios [21]. Sun Xueliang expounds on tag-oriented and multi-tag website traffic identification attacks and discusses their principles in 2021 [22]. Lashkari A H et al. proposed a temporal feature-based Tor fingerprinting attack in 2017 and released a test dataset [23]. In 2020,Florian Platzer proposes a Tor traffic analysis method that allows attackers to de-anonymize any hidden service in less than 12.5 days, which poses a threat to online anonymity [24].
Man-in-the-middle attack: For the Tor system, by deploying a "malicious man-in-the-middle", a man-in-the-middle attack is launched on the link in the anonymous communication system. The simplest attack is to disguise a node as a man-in-the-middle between two nodes in the link, thereby destroying the communication link. Sanatinia A et al. in 2017 demonstrated that an attacker who cracked the private key can launch an attack on a hidden directory server [25].
Sybil attack:The witch attacker forges enough relay nodes, and the user has a high probability that the 3 relay nodes selected in a row are all nodes forged by the witch attacker, which will cause all the user's data to be decrypted. Philipp Winter et al. developed a sybilhunter Sybil attack tool in a real network in 2016 and experimentally proved that Tor cannot resist Sybil attack [26].
Replay attack: In 2008, Pries et al. proposed an anonymous network source tracing technology based on replay attack, which adopts the scenario mode of AES calculator encryption mode AES-CTR. The attacker intentionally modifies the value in the counter, resulting in an asynchronous situation, which in turn exposes the communication status of the network. By controlling the nodes in the anonymous network, replaying the communication data causes the node to fail to receive the data so that the communication relationship between the two communicating parties is also manifested [27].
Attacks against Tor are not limited to the above-mentioned attacks. Figure  2 depicts the Tor system, where attackers launch attacks, and the main attacks they face. Attackers can launch traffic identification attacks and man-in-themiddle attacks by detecting the traffic from the client to the entry node. Replay attacks by intercepting traffic at ingress and egress. DoS attacks against single or multiple servers in the Tor network. By controlling multiple Tor relay nodes, launching Sybil attacks, etc.

Tor Architecture Vulnerability
Disclosure of consensus file :The IP address of the directory server in the Tor system is exposed to the whole network. Anyone who wants to obtain the consensus file can obtain the consensus file of the entire system by sending a GET request to the directory server. Therefore, after obtaining the IP of the directory node, the attacker can simulate the client to send a Get request to the directory server. You can directly enter this type of URL http://IP:port/tor/status-vote/current/consensus.z in the browser to get the plaintext consensus file. Part of the consensus file is shown in Figure 3. The plaintext consensus file will contain the following sensitive information: IP address, region, bandwidth, Tor version, etc. of the intermediate nodes of the system. Once the attacker obtains the information of all relay nodes in the whole network, he can launch DOS, cryptography, and other attacks on it in a targeted manner. This behavior of exposing distributed nodes to the entire network has obvious security risks.
Directory server centralization: Tor directory servers are 10 authoritative directory servers officially formulated by Tor. Tor authoritative directory servers are distributed in 6 countries in North America and Europe, 5 in North America, and 5 in Europe, including 4 in the United States, 1 in Canada, 1 in the Netherlands, 1 in Austria, 2 in Germany, and 1 in Sweden. The specific bandwidth and update time and other information are shown in Figure 4 [28].
It can be seen that 7 of the 10 directory servers support IPv6 address access, and all the information of the nodes is public, such as the directory server's address, running time, bandwidth resources, and so on. The directory server has functions such as measuring node information and voting to generate consensus files. Attackers can attack these public directory servers. If they control more than half of the directory servers, they can tamper with the consensus files and destroy the anonymity of the overall system. At the same time, regulators can block the IP addresses of the above directory servers. Using this blocking method will make users unable to access anonymous communication networks. Article Title  At the same time, the Tor directory protocol also has shortcomings. Tor's 10 directory servers are "hard-coded" into clients as well as intermediate nodes [29]. As a result, when some authoritative directory servers are added and deleted, the program source code must be updated, which increases the cost of deployment and reduces the scalability.
Presence of malicious nodes: At present, there are roughly more than 6,500 distributed relay nodes and more than 1,700 bridge nodes in the entire network. Most of these nodes actively join and quit. Tor has no authentication mechanism for relay nodes, and there are a large number of unreliable relay nodes in the network. Attackers can deploy malicious nodes to steal and analyze the communication relationship in the link and destroy anonymity. And attackers can exploit existing vulnerabilities to attack these nodes, spread bots through various channels, infect a large number of hosts, and form botnets.

Tor proposal
Since February 2018, the Tor community has submitted 48 proposals to the official Tor team[31], including improvements in security and performance. Among them, 23 proposals provide solutions for the security problems faced by Tor, 18 proposals provide solutions for Tor performance optimization, and 7 proposals provide improvements in other aspects. These proposals show that Tor still has corresponding problems in Dos attacks, censorship-resistant attacks, malicious node-in-the-middle attacks, and scalability.
At present, some scholars have used blockchain to realize anonymous communication between IoT devices [32]. The system divides the communication scope into two domains through centralized authentication and decentralized anonymous communication mechanisms. The zero-knowledge proof of identity is realized through the Merkle tree, the identity of administrator nodes is obfuscated and the association attack is resisted through aggregated signatures. Defects: IoT devices have high communication delay due to hardware performance and network environment limitations. And complex authentication and node management mechanisms are not suitable for large-scale users.
Qin Wang proposed a consortium system based on anonymous blockchain in 2021 [33]. Since the data on the blockchain is open and transparent, a privacy system for protecting the blockchain-MAB is proposed. This system belongs to the application of privacy protection in the blockchain and lacks the versatility of anonymous communication systems.

Threat Model
Consider an experienced attacker with sufficient computing power in the network who is trying to attack an anonymous communication system. The first consideration is the DOS attack. The attacker tries to perform a denial of service attack on the important nodes in the network so that it cannot serve other normal nodes, which makes the overall anonymous communication system unusable. This attack is generally effective against current anonymous communication systems such as Tor, and it is also the most difficult to defend against. B-Tor first adopts the blockchain distributed architecture, and each node is a peer node, which is a decentralized architecture. Secondly, the identity of the node is not fixed, the node will periodically run the reputation function (see 5.2) and redistribute the node function by calculating the reputation value. It makes it impossible for the attacker to select an important node to attack. If an ordinary node is attacked and paralyzed, the overall system will not be unable to run due to the offline or failure of a node. If an important node is paralyzed by an attack, the system can resume operation by redistributing node functions. Therefore, DOS attacks can be effectively prevented.
Second, consider malicious nodes joining. For the public anonymous communication system, malicious attackers join the system by pretending to be honest nodes. By passively collecting the traffic in the network, analyzing the time interval and the size of the data packets etc. It can determine whether there is a relationship between two users in the network. At the same time, the attacker can also hijack the traffic packets in the network, mark a group of traffic by discarding or modifying the traffic packets, and detect the traffic packets with this characteristic at a specific location, to analyze the correlation between users. B-Tor is a registered anonymous communication system. Nodes need to apply for registration to enter this anonymous communication system, which prevents malicious attacks from attackers. And in this way, the consensus file will not be exposed on the public network, which reduces the risk of being attacked by the exposure of distributed nodes in the system. At the same time, the authentication and node reputation management mechanism is introduced, which has a certain control effect on the behavior of joining nodes.

B-Tor Design Concept
Traditional distributed anonymous communication systems can be mainly divided into two categories, one is anonymous communication systems based on relay jumps, such as Tor, SGX-tor, shadow-walk, AP3, etc. One is the anonymous communication system based on the shuffling mechanism, such as loopix, riposte, Dissent, Atom [34]. The common problem is high network latency and weak defense against traffic analysis attacks by malicious nodes. The fundamental reason is the lack of censorship of malicious users and the identification of malicious users, and the complex network environment, the anonymous communication system bandwidth follows the barrel effect (the actual bandwidth is the maximum delay bandwidth in the node), which leads to the above-mentioned public anonymous communication System latency is high. At the same time, these anonymous communication systems have become criminal sanctuaries due to illegal abuse.
At present, when legitimate users use the Internet, they do not need to use anonymous communication systems in most cases. However, in special cases, legitimate users need to use anonymous communication systems to protect the legitimate behavior of individuals. However, it is blocked by many countries due to the above-mentioned hazards. In addition, the performance of network nodes is uneven, resulting in a large network delay. Therefore, the user's anonymity needs cannot be well satisfied. For example, the following legitimate anonymous requirements: (1) Anonymous reporting: users prevent malicious personnel from retaliation, and do not want their behavior to be discovered and tracked by others. (2) Anonymous voting: Users vote according to their wishes and do not want to be discovered by other users. (3) Anonymous award: users need to hide their identity to prevent others from hurting themselves maliciously due to jealousy. (4) Anonymous charity (5) Anonymous medical treatment: Patients are reluctant to reveal their identities to doctors and other groups of people. (6) Anonymous mailboxes of government departments, etc.
B-Tor was designed due to the above requirements and is a traceable anonymous communication system. The system requires users to trust an institution with strong credibility. The agency can be a national-level regulatory agency, such as Police Department, National Security Agency, etc. For example, in the above requirements: (1) Anonymous reporting, users trust the reporting agency. (2) Anonymous voting, users trust the voting institution. (3) To receive the award anonymously, the user trusts the awarding institution. (4) Anonymous charity, users trust charities. (5) Anonymous medical treatment, users trust medical institutions. (6) Government anonymous mailbox. Users trust the government and so on.
The above-mentioned trusted institutions cannot interfere with the normal behavior of users. Only when the user conducts illegal acts, the public trust agency can restore the registered identity of the anonymous user through the group signature according to the characteristics of this anonymous communication system. The public trust agency can restore the identity of the malicious user after obtaining the consent of the vast majority of legitimate users by broadcasting a retrospective request to the user. To achieve the purpose of traceability and supervision. From the perspective of game theory, if most legitimate users collude with public trust institutions to expose the identity of a legal user, then this behavior is detrimental to both legitimate users and trust institutions. Exposing an attacker or illegal user who has an impact on the system and society is beneficial to most users and institutions.

B-Tor System Architecture
Because of the shortcomings of the above-mentioned anonymous communication system Tor, this section introduces an anonymous communication system B-Tor based on the consortium blockchain. In this anonymous communication system, the bottom layer uses Tor's onion routing protocol and three-hop proxy communication mechanism to ensure the anonymity of users. At the same time, the upper layer uses the consortium blockchain technology in the blockchain technology, combined with the decentralization, non-tampering, and traceable characteristics of the blockchain, to solve the above problems.

Overview of B-Tor Architecture
This anonymous communication system is anonymous communication within the Hyperledger Fabric framework. The roles of the relay nodes in the original Tor network are divided so that the system operation is more stable and the node functions are clearer. This anonymous communication system needs to run on the Fabric distributed framework and consists of the following five components. The following describes each component and function.
Client node: The purpose of the client is to establish a link and initiate a session for the user, through which the user accesses the anonymous network. The main functions of the client are: send a registration request to the CA and obtain the consensus file for the first time, join the anonymous network, install and instantiate the chaincode, obtain the consensus file (steps 1-2 in Figure 6), and establish three based on the client's path selection algorithm. Hop nodes to build links (step 3 in Figure 6), etc. Relay node: The relay node is also called Peer. This node has the function of proxy forwarding and is a thoughtless node. At the same time, relay nodes are divided into four types: storage peer, verification peer, leader peer, and anchor peer. All types of peers have the functions of initiating registration requests to the CA (Certificate Authority), uploading and downloading distributed storage consensus files, and forwarding by three-hop agents. The verification peer has the unique function of verifying the chaincode. The verification peer is responsible for receiving the chaincode request submitted by

Registration and initialization
There are different participants in the B-Tor anonymous communication system, including relay nodes, client nodes, order nodes, etc. Nodes need to register their identity to join the network. Each node participating in anonymous communication has a digital identity encapsulated in an x.509 digital certificate. These identities are important, they limit the access rights of nodes in the anonymous network, and whether to connect to the anonymous network. B-Tor CA (CA for short) is a certificate authority that manages the identity of network nodes. It has the following functions: identity registration, issuance of certificates, and revocation of certificates. Identity registration and certificate issuance: (1) Register the boot ID. First, the node runs the B-Tor program and sends a registration request to the CA by constructing a boot identification command. The registration command will store the registration ECert(certificate) , the corresponding private key, and the certificate file PEM obtained from the CA request in the identity management directory MSP (member service provider) of the node.
(2) Register a new identity. Before registering a new identity, the CA checks the node. Three main aspects are checked. 1) Check whether the registered identity belongs to the corresponding organization. For example, if peer0 belongs to org1, then its registered identity must be peer0.xxx.org1.com, and the identity of other organizations cannot be registered. 2) Check whether the node has a boot ID, and check the node identity so that it cannot register a node that does not belong to its own identity. For example, client nodes cannot be registered as relay nodes or order nodes. 3) Check whether the node has been registered, and query the node's historical information and noderelated attributes. If the node is registered, the check fails. A node that satisfies all of the above conditions can register an identity with attributes such as registration ID.
(3)Registration password. The node sets a registration password, and the system provides the registration ID and registration password to other nodes that have passed the registration for authentication between nodes during communication.
(4)Distribute consensus file. When the node is successfully registered through the above process, the CA sends the first consensus file. At this point, the new user completes registration and joins the network.
A consensus file contains three attributes: node ID, consensus file ID, and consensus file update time, of which the node ID contains 10 sub-attributes. The structure is shown in Figure 7.
Revoking a certificate: When the node information faces the risk of leakage or malicious behavior, the identity or certificate can be revoked. Revoking an identity will revoke all certificates owned by that identity and will also prevent that identity from obtaining any new certificates. Revoking a certificate will invalidate a single certificate. And generate a certificate revocation list after the revocation is complete. All requests by the CA server to receive a node whose identity has been revoked will be rejected.

Link Establish
Through the above process, the user completes the registration and obtains a consensus file with a description of the network topology. This section describes that the user obtains the IP address, bandwidth, and other information of the relay node in the system by parsing the consensus file (introduced in 5.1). Then start to establish a three-hop link. (1) Select the node with the highest reputation value (reputation value calculation is introduced in 5.2) as the first hop entry node Peer1; (2)The client first sends a link establishment request to Peer1. After Peer1 verifies the legitimacy of the client, it will generate a pair of keys, the public key pubkey Peer1 Client and the private key prikey Peer1 Client. Then send the public key pubkey Peer1 Client back to the client (so far, the client has successfully established its communication link with Peer1); (3) The client selects a relay node Peer2 with a relatively high reputation value from the obtained consensus file, and sends a data packet to Peer1: use pubkey Peer1 Client to encrypt the address of Peer2; (4) After Peer1 receives the data packet, it uses its private key prikey Peer1 Client to unpack the data packet, and finds that it is a request to establish a link between itself and another server, Peer2, then Peer1 repeats (2) to establish a link with Peer2, and Peer2 The returned public key pubkey Peer1 Peer2 of the link between Peer1 and Peer2 is returned to the client; The client repeats steps (3) and (4) to establish a communication link between Peer2 and Peer3, and receives the public key pubkey Peer2 Peer3 of the link between Peer2 and Peer3; So far, the link between the client and the three relay servers has been successfully established, and the client has three public keys: pubkey Client Peer1, pubkey Peer1 Peer2, and pubkey Peer2 Peer3. At this time, the client communicates anonymously through the three-hop proxy.

Network topology update
The network topology changes due to the addition and departure of relay nodes in the network. For the client and other relay nodes in the network to correctly obtain the network topology, the consensus file needs to be updated. Tor uses a directory server to centrally generate consensus files so that clients can obtain new network topologies. The client accesses the directory server through HTTP request to obtain the consensus file, which makes the Tor directory server centralization problem. To enhance security and resistance to censorship, we introduce a method for issuing consensus file through blockchain consensus.
The following specifically describes how to update the network topology through these four types of nodes. In 4.1, it is mentioned that the relay node Peer is divided into four types: storage peer, verification peer, leader peer, and anchor peer.
For example, when Peer0 joins the network, the network topology is updated.
1)The Peer0 node registers and joins the anonymous network through the joining method described in Section 4.2.1.
2)The Peer0 node broadcasts its node information to the network and records it in the blockchain. Specifically, first Peer0 joins the channel and obtains the chaincode in the channel. The function of the chaincode is to upload its attribute information to the blockchain according to the specified format and broadcast it to the network.
Peer0 first constructs the identity information and sends a request to execute the chaincode to the verification peer (shown in Figure 8, step 1). The verification peer checks its identity and simulates the execution of the chaincode. When the verification node checks that the node is a valid network member node and the chaincode simulation is executed correctly, it will sign the result and send it to Peer0 (shown in Figure 8, step 2).
After Peer0 gets the signature of the verification peer, it will send the signature to the order node and request to execute the chaincode. (shown in Figure 8, step 3).
The order peer does not verify the content of the chaincode, directly executes the chaincode requested by Peer0, and sorts the execution results. After sorting, the information of Peer0 is packaged into blocks and linked to the blockchain. (Shown in Figure 8, step 4 ) The order node broadcasts Peer0 information to the leader peers of each organization. (The internal broadcast of org1 shown in Figure 8, step 5) The leader peer of each organization is responsible for synchronizing the broadcast to every node in the organization. Each peer in the organization will record Peer0's information in the local ledger, complete a new peer joining the network and record the node joining information in the blockchain. (shown in Figure 8, step 6)

Fig. 8: Peer0 uploads information and issues consensus
3) Peer0 will periodically perform step (2) to synchronize its information to the system and broadcast the information to other peer in the network. The time set by this system is 10 minutes (which can be adjusted later), and the peer will automatically run the chaincode for updating its information regularly. After execution, each peer gets the latest information of Peer0 and updates the local consensus file. 4) If the Peer0 leaves or fails at a certain time, the chaincode cannot be executed regularly, so that the timestamp attribute in the Peer0 cannot be updated, so the timestamp information of the Peer0 in the local records of each peer is not synchronized with the current time. According to the node management and incentive mechanism to be introduced in 5.2, such nodes will not be selected as available nodes and will be automatically eliminated as the system runs.
Through the above method, each node can obtain a consensus file without using a directory server, and the network topology can be updated more conveniently. B-Tor does not have a centralized architecture, making the system more secure.

Anonymous registration and traceability
Register anonymously: The fourth section introduces that users need to register and manage the identity of network participants through B-Tor CA, but the way of registration will affect the anonymity of users. Aiming at the above problems, this paper proposes a node anonymization mechanism based on group signature. This registration mechanism adds a privacy protection method to the node authentication module in Hyperledger Fabric to ensure the anonymity of users and the security of the system.
The registration module consists of 5 parts, including RTCA (Root Certificate Authority), Fabric-CA cluster, B-Tor client node, relay node, and supervisor. The authentication part consists of a server cluster. The CA Server node is constructed in a tree structure, which includes a core RTCA node and multiple middleware nodes (Fabric-CA Intermediate Server). As shown in Figure 9. Node anonymous registration is mainly divided into 6 steps:

1) Root certificate generation:
When a consortium blockchain is being created, members of the consortium blockchain designate a node as a CA node through a configuration file. Then select a trusted third-party proxy certificate issuing agency RTCA (Root Certificate Authority) to generate RTCERT (Root Certificate). RTCERT is the root digital certificate of the entire network in B-Tor. The agency issues a sub-root certificate to the Fabric-CA intermediate Server according to RTCERT and writes the sub-root certificate into the configuration file when the consortium blockchain is created. As shown in 1 ○ in Figure 9.

2) Group public-private key generation.
After the consortium blockchain is started, CA nodes execute the generation of group public key and group private key for group signature, package the group public key information into a transaction, and then broadcast the transaction within this consortium blockchain, as shown in Figure 9 ( 2 ○). After the nodes reach consensus, the transaction is uploaded to the certificate blockchain (CertBlockChain) as a genesis block. At the same time, the group private key information is encrypted and packaged into a transaction, and the recipient of the transaction is the supervisory node of this federated chain. After that, the broadcast consensus is made and the transaction is uploaded into CertBlockChain, as shown in Figure 9 (3).
For the node that needs to join the consortium blockchain, the node initiates a registration transaction to the CA node, which contains the node's public key and necessary identity information; the CA node issues an access certificate ECERT (Enrollment Certificate) to the node after verifying the identity information it provides. At the same time as dispatching the ECERT, the CA issues a group certificate GCERT (Group Certificate) to the node. In this system, all nodes need to apply for the unique identity ECERT. both ECERT and GCERT are generated based on the node public key, and this process is shown in Figure 10, 1-3.

4)Issuance of consensus file.
The node that is successfully registered in the consortium blockchain provides the ECERT of the node and initiates the operation of obtaining consensus file to the CA node, which generates the TCERT (Transaction Certificate) of the pair by verifying the ECERT and issues the consensus file and TCERT to the corresponding node. Nodes can apply for TCERTs in advance when no transactions are made and can apply for multiple TCERTs in bulk. this process is shown in Figure 10, 4-5.

5) Transaction certificate up-chaining:
After the node has applied for TCERT to the CA node, the CA node needs to package the application into the transaction and up-chain the transaction to CertBlockChain to block-chain the consensus file and certificate dispatching for subsequent finding and supervision. The process is shown as 3 ○ in Figure 9. 6) User and node information maintenance. CA needs to maintain a URT (UserRegisterTable). When CA completes the registration of a node or abolishes a node authority according to the corresponding conditions, it needs to update the URT and keep the user data in the URT in a real-time updated state.
Traceability: Nodes publish cross-chain transactions within the consortium blockchain and need to set a flag bit in the transaction to identify the cross-chain transaction. At the same time, it uses GCERT to sign the transaction and generate a group signature. Finally, the signed transaction is broadcasted within the consortium blockchain. For nodes that have issued registration requests, CA or supervisory nodes trace the group signature of such transactions through the group private key to obtain the identity of the signer, to achieve the supervision of the deanonymization of the members of the consortium blockchain and ensure that the identity of the signer of such transactions is not known to other members of the anonymous network.
At the same time, the sub root certificate and CA node information generated by RTCA, a third-party organization, will be packaged into a transaction and broadcast to the whole consortium blockchain network to finally reach a consensus. the generation of group public-private key by CA is automatically triggered by the configuration file when initializing the consortium blockchain. When CA generates GCERT for a node, it needs to bind ECERT and group public key. And GCERT contains the identity information of the node, when the regulator needs to de-anonymize the node, the identity of the node can be recovered by the group private key.
Through the above-mentioned group signature, the registered users can be anonymized and their identities can be protected. The introduction of the registration mechanism increases the cost of malicious node attacks to some extent and increases the trustworthiness of relay nodes to avoid zombie nodes from disrupting the network. At the same time, combining the characteristics of group signature and blockchain, the identity of the evil node can be recovered through the supervisor when there exists a node to do evil, which achieves the purpose of traceability for malicious users. This traceable anonymous communication system, to a certain extent, prevents the abuse of anonymous networks from bringing social insecurity.

Node Management and Incentive Mechanism
Node management: It is mentioned in the system architecture that different relay nodes have different attributes and functions so there will be the following disadvantages compared to the Tor relay node which has the same function. The verification peer is responsible for the overall system transaction validation, the leader peer is responsible for the dissemination of the consensus file down in the system, and the anchor peer is responsible for the cross-channel communication of the system. This solidification of node functions can easily lead to insecurity of the system and the possibility of malicious nodes committing mischief in the long run. Therefore, B-TOR introduces a node management mechanism that calculates the reputation value of each node and assigns and adjusts the node functions according to the different reputation values.
First, after each relay node installs the B-TOR program and joins the system, it automatically deploys a Reputationfunc smart contract that calculates the reputation value and provides an API for external calls to this smart contract, which is forced to run in the anonymous communication system and cannot be modified by the user in terms of execution process and sequence. The Reputation function generates its Reputation value, which is written as an attribute of the node in the consensus file and is available to other nodes in the system.
By judging the reputation value, the function of each node is assigned and whether it can join this anonymous network or not. The overall flow of the system is shown in Figure 11. When the reputation value is invalid, the node will be denied access to the network. When the reputation value is valid, the identity is reassigned. At the same time, nodes that are denied access to the network can request access to the network again and recalculate the reputation value. According to the behavioral attributes of nodes, they can be divided into irrational and rational behaviors. More irrational behavior means that this node is more unreliable and unstable, and similarly, the higher rational behavior of a node means that the node is more stable and trustworthy. Tables 2 and 3 specify the rational and irrational behaviors.
Firstly, the node needs to execute the chaincode and request the verification peer to verify it (as shown by 4.2.3 Execution flow). Specifically, the node sends  When a node communicates with other nodes, it deceives the trust of the other party and provides false transaction information.

Slander
When a node communicates with other nodes, it attacks other nodes in various ways.
Assume another's name Nodes impersonate other nodes and perform the functions of other nodes.

Lurk
The node does not act and does not perform the function of its own node.

Conspire
Nodes collude with other nodes to improve each other's reputation, or collude to attack the system.

Reentry
Nodes frequently access the system, or re-enter the system by changing their identities. The bandwidth of nodes is significantly higher than that of ordinary nodes.

Online time
The online time of the node is longer, and the communication with other nodes is more frequent.
Provide service time Nodes provide more proxy communication and high data integrity.

Historical reputation
Rich node history and high reputation values Computing power Nodes take less time to execute transactions and publish them on the blockchain.

Number of local ledgers
The local ledger capacity of the node is large, and the historical data is stored more.
the execution content to the verification peer, at which point the verification peer verifies the authenticity of this Peer node content. The verification node calls the Reputationfunc smart contract API of the Peer node from outside and gets a copy of the execution result. The behavior of the Peer node is verified by judging whether it is consistent with the information submitted by the Peer node. Based on the behavior verification node will further modify the reputation value submitted by the Peer node to ensure the authenticity of the node information.

Reputation calculation function Reputationfunc:
Reputation calculation function will calculate reputation value Reputation based on the above user behavior, rational behavior by executing the function Contribution() to obtain rational behavior value. Irrational behavior is calculated by executing the destroy () function to obtain the irrational behavior value γ.The Reputation value Reputationj of node Peer j is calculated by the function.
Where α j i denotes the ith rational behavior value of Peer j. γ j i denotes the ith irrational behavior value of Peer j.
where n is the number of times Peer j performs the reputation function in the system. β is the damage degree factor, and β can be adjusted according to the later need. If a node has irrational behavior, the value of irrational behavior of the node will show an exponential increase, which makes the overall reputation value of the node drop, and when the reputation value of the node drops to 0, this node cannot be used. Whenever the system performs a reputation function, its value will be stored in the blockchain, which is called historical reputation, and each node keeps up to 10 recent historical reputation values.
Incentive mechanism: Also in distributed networks, intermediate nodes are responsible for message forwarding, and artificially deploying a large number of nodes will increase the cost of running anonymous networks. An incentive mechanism needs to be considered to make relay nodes join as volunteers voluntarily. This is specifically achieved through the above-mentioned node reputation, which is obtained by the node and does not disappear when the node leaves the system but is permanently stored in the blockchain network. Client nodes can communicate anonymously based on their reputation, and when a relay node wants to convert to a client node, it can obtain the reputation of the relay node belonging to itself in the blockchain-based on its private key (refer to the Bitcoin wallet mechanism here, where Bitcoin users can obtain bitcoins in the wallet based on their private key). The credibility translates into credit for using the B-Tor anonymous communication system, the higher the credit the longer the time to communicate anonymously. This allows client nodes that need anonymity to voluntarily join the relay nodes. At the same time, users consider the impact of reputational value, which discourages irrational behavior.

Evaluation
For the experimental testing of the above architecture, the operating system used was Ubuntu 1604, the CPU was AMD Ryzen 9 5900X, the RAM was 16G, the SSD was 100G, and the default consortium blockchain framework was Hyperledger Fabric v2.0.0. The test was opened in two organizations with a total of 10 test nodes, and the experiment first deployed Hyperledger Fabric consortium blockchain environment and deploy B-Tor to that environment.
By writing chaincode in go language combined with fabric-go-sdk, we implement operations related to registering nodes to join the network and obtaining distributed node information in the B-Tor system. This includes 1) initialize the consensus file. 2) add nodes. 3) update node information. 4) query node information by node ID. 5) get a new consensus file, etc.
After the client nodes and intermediate nodes deploy the B-Tor program, they will execute the internal chaincode, and the initialization operation will be performed when the program starts, and the chaincode will be installed. This action will check the user and client identity, and the chaincode can be executed if the identity requirements are met. When the program is initially run, the consensus file is initialized, and it is necessary to execute initConsensus().
Experiments related to client access to the consensus file are also conducted. The number of times the consensus file is successfully acquired is counted by 10 client nodes continuously acquiring the consensus file. Figure 12 shows that the B-Tor client continuously acquires the consensus file in 600s time, and the total number of successful acquisitions is 790629 in 600s. The delay of acquiring consensus files for 10 clients is also tested, and the average is around 0.1s. The experiments show that the B-Tor anonymous communication system has significantly shorter latency and a higher success rate in acquiring consensus files by clients. It is suitable for large-scale distributed networks. We used the  [35]with the Tor performance simulation tool tornettools to perform simulation experiments [36]. The experiments were conducted using the real official Tor data[37]and scaled down to 0.005% of the real network. Three directory servers and 6746 intermediate nodes were used and the simulation duration was 600 s. This experiment makes comparisons in terms of link communication round trip time, consensus file acquisition time, data transfer time, and link establishment time.
The average time for Public-Tor to build a three-hop link and communicate back and forth is shown in Figure 13. Public-Tor takes 1∼2 s, and a few roundtrip links take more than 5 s. B-Tor takes about 1 s, and the longest time is 2.2 s. It is better than public-tor in terms of time and stability.
The average time to obtain a consensus file is 2.2s for public-Tor(show in Figure 14), and 1.2s for B-Tor. the performance of the network can be judged by the time to obtain a consensus file, and the time to obtain consensus file is also the main factor to determine the network latency. Compared to public-Tor, this anonymous communication system has lower latency.  The transmission rate is an important indicator of anonymity network performance(show in Figure 15). This experiment compares public-Tor and B-Tor by sending a 1M packet at the same time and measuring the average time. public-Tor takes 4 5s on average and some packets are lost, B-Tor takes 2.5s on average and the transmission process is more stable than public-Tor.
Link establishment time directly affects user experience and is the main criterion for evaluating anonymous network performance. By obtaining the link establishment time several times, we obtain the relevant data and plot the link establishment time CDF(Cumulative distribution function)diagram in Figure 16. Compared with public-Tor, the link establishment time of B-Tor is significantly shorter, with 95% of nodes being established within 1 second. The average time reduction is one-third of that of public-Tor.
This system load was tested by Hyperledger Caliper [38] on the performance of the chaincode and the system load. We focus on the read consensus file function and thus test the read and write performance of the system. The test environment is an Ubuntu 1604 virtual machine with AMD Ryzen 9 5900X CPU and 16G RAM. Table 4 shows the system resource consumption in the docker environment, using Peer0 node of organization 1 to test the system load, from which we can get the maximum system CPU load rate of 77.36%, the average CPU usage CPU 32.34%, the maximum number of memory used 129M, the average Also, the initial test used two clients, cyclic test 30s to get the test results, showing the read 19,483 times, the success rate of 100%. The send rate was 657.9 TPS and the system throughput was 657.9 TPS. Figure 17 shows some of the results of this experiment.
And for two clients, circular call to obtain consensus file chaincode for the 30s, Figure 17 gives the report results.
According to the above test method, the performance test is conducted by increasing the number of clients and changing the cyclic reading time. Specifically, 10 clients were used to cycle through the 60s, 100s, 120s, 180s, and 300s to see the system load. The system throughput was relatively stable during the 600s test time, reaching an average of 1312.9TPS and a maximum of 1352.8TPS. Figure 18 shows the results of this test.
From the experimental results we get the system overall increases the number of executed transactions as the test time increases. This system has a large throughput and sending rate and can remain relatively stable and unchanged during the long-time cyclic test.

Summary
With the continuous development of network security, data security and personal privacy security have been gradually concerned by the state and society. cryptographic algorithms ensure the security of data contained in Internet communication, and anonymous communication technology ensures the security of user privacy in Internet communication. tor is currently the most widely used open-source anonymous communication system, and with the use of tor, more and more people are studying its characteristics and security. In this paper, we analyze the Tor architecture, and deeply analyze the existence of centralization and other security issues in the Tor architecture. In addition, we apply the decentralized, tamper-evident and traceable features of blockchain to the Tor architecture to generate a consortium blockchain-based anonymous communication system B-Tor. The design idea of this paper adopts the consortium blockchain as the underlying architecture of B-Tor. It is specifically implemented through Hyperledger Fabric, the most widely used in consortium blockchain. The consensus file of the whole anonymous communication system is stored through the Hyperledger of each peer node. B-Tor has the following features: protection of users' normal anonymous communication, verifiability of joined relay nodes, traceability of transactions against crimes, and distributed storage of consensus files to solve the problem of directory server centralization. Section 1 of this paper illustrates the importance of the existence of anonymous communication systems and presents the problem of misuse of Tor to make it unusable for some users. Section 2 specifies the architecture of Tor and blockchain technology and introduces the current attacks and flaws faced by the Tor network. Section 3 gives the current threat model of anonymous communication systems in response to these flaws and describes the B-Tor design concept. Section 4 specifies the overall system model of B-Tor, as well as the functions and implementation methods of each module. It also explains the introduction of a new consensus file update and distribution method compared with traditional Tor, and the addition of node management functions to ensure more security during system operation. Section 5 presents the experiments and analysis of this system, and the advantage of B-Tor over Tor is the different way of obtaining consensus files. The first section of Section 5 demonstrates B-Tor's access to consensus files in the consortium blockchain and the related comparison tests. It also shows the advantages of high throughput and high performance compared to public blockchains due to the use of the Fabric consortium blockchain architecture. The second subsection demonstrates the load of the system when B-Tor is cycling through multiple users to obtain consensus files. Finally, the analysis results of this system are given.
This paper only makes a preliminary attempt for the anonymous communication system Tor combined with blockchain, and the next work needs to be done to improve and think about the following aspects: for how organizations and users join and exit the system in most consortium blockchains. This experiment is relatively simple, without large-scale users for testing, while the number of organizations joining the consortium blockchains is small, and the system performance needs further analysis.
The underlying source code of Tor and the mechanism of establishing and selecting links have not been modified, and the characteristics of Tor traffic still exist. Further research is needed on fingerprinting attacks and other ways to target traffic.
Regarding node management, a method to calculate reputation worthiness is introduced, and it is hoped that a more secure and stable node management algorithm can be added on this basis subsequently.

Declarations
Ethical Approval and Consent to participate:Not applicable Human and Animal Ethics:Not applicable Consent for publication:Not applicable Availability of supporting data:All data generated or analysed during this study are included in this published article Competing interests:The authors declare that there is no conflict of interest regarding the publication of this paper.
Funding:Not applicable Authors' contributions:Dawei xu and Jiaqi Gao write papers and do experiments. Liehuang Zhu and Feng Gao proposed and designed the key technologies of this paper. Yang Han and Jian Zhao collect experimental data and find information.