# BBARHS: Blockchain-Based Anonymous Ride-Hailing Scheme for Autonomous Taxi Network

Authors: Kun Wang; Mingzhe Liu; Jianping Wang; Min Wu; Feixiang Zhao
Journal: Security and Communication Networks
 (2022)

---

## Abstract

In the past few years, ride-hailing platforms such as Uber, Waymo, and Baidu have built their own autonomous taxi system. Unlike public transit services, ride-hailing platforms raise severe privacy issues. To provide excellent autonomous taxi service, some significant security and privacy problems must be addressed. In this study, we present the security and privacy threats and first proposed blockchain-based anonymous ride-hailing scheme (BBARHS) for autonomous taxi network. We give the formal system model and security model of BBARHS. Then, we outline the concrete BBARHS scheme by making use of Monero and some efficient crypto tools. Through security analysis and performance analysis, the designed scheme is provably secure and efficient. The analysis results also show the designed BBARHS scheme is practical for autonomous taxi network.


---

## Body

## 1. Introduction

With the development of information technology and AI, autonomous vehicles (AVs) come true. One of the most discussed potential use cases of AVs is RHS (ride-hailing service). AVs and public transit would cut traffic by 90%. It could be 10 times cheaper to take E-AVs taxi than to own a car by 2030 [1]. Waymo, a company owned by Google, officially obtained the first commercial automatic driving taxi service license and took the lead in launching relevant services in Phoenix, the United States [2]. Autonomous Lexus has been tested in California, Michigan, and Japan and preparing for real-world use during the 2020 Tokyo Olympics. Chinese ride-hailing giant Didi expects at least 10% of vehicles to be highly autonomous by 2025, and fully autonomous by 2030 [3]. But in fact, under the existing technical conditions, there are still many challenges and difficulties for the autonomous taxi to achieve commercial scale on the actual road. Without the passengers’ knowledge, Uber collected information including passengers’ names, e-mails, boarding locations, spending amounts, etc. Autonomous taxi network consists of riders, RHS, and AVs. An autonomous taxi system needs to meet various indicators, for example, performance, safety, and stability [4, 5].Over the past decade, blockchain as the backbone of bitcoin has experienced a rapid development [6]. Many researchers explore blockchain application scenarios [7–9]. A blockchain is essentially a distributed database of records, or public ledger of all transactions or digital events that have been executed and shared among participating parties. Each transaction in the public ledger is verified by the consensus of a majority of the participants in the system. Once entered, information can never be erased. The blockchain contains a certain and verifiable record of every single transaction ever made [10]. The basic structure of blockchain is shown in Figure 1.Figure 1
The basic structure of blockchain.The blockchain uses digital signatures to determine the identity of the sender of information. A digital signature is a digital string that can only be generated by the sender of the message, and this digital string is also an effective proof of the authenticity of the message sent by the sender. It is a kind of ordinary physical signature similar to that written on paper, but it is realized by the technology in the field of public key encryption, which is used to authenticate digital information. Bitcoin uses an elliptic curve digital signature algorithm (ECDSA) to generate public and private keys for accounts and to verify transactions and blocks. The ECDSA is an analog of the digital signature algorithm (DSA) using elliptic curve cryptography (ECC).The cryptographic hash function is a type of hash function. An arbitrary amount of data input of this hash function is usually called a message, and its fixed-size output result is often called a hash value. The secure hash algorithm (SHA) is a series of cryptographic hash functions designed by the National Security Agency (NSA) and published by the National Institute of Standards and Technology (NIST), including SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 variants. Bitcoin uses SHA-256. That is, no matter how many bits the original data have; as long as the hash operation is passed, the length of the result is fixed as 256 bits.Representative projects of public chains such as bitcoin and ethereum use POW and POS consensus algorithms. Miners use SHA-256 to calculate the hash value that meets the difficulty target value (starting withN zeros). Representative projects of the alliance chain such as hyperledger fabric use PBFT as the consensus calculation method. Nodes use digital signatures to directly exchange information to reach a consensus. Blockchain guarantees the authenticity, privacy, and security of information through cryptographic tools and consensus algorithms.Riders need to exchange information between multiple participants, and privacy protection and the authenticity of information are extremely important. This article aims to use the characteristics of blockchain technology to solve these problems in the field of autonomous taxi.


### 1.1. Motivation

Security and privacy problems are the two major problems that need to be solved urgently for autonomous taxi network. In order to be able to provide services, the system needs to manage the location information of autonomous taxi, rider standards, service scenarios, how much fuel there is, and so on. After that, an autonomous taxi is allocated based on the service information requested by the rider. Finally, the rider needs to pay for the service. In these processes, how to protect the privacy of rider and how to ensure the safety of autonomous taxi are very important. If privacy of rider and autonomous taxi is leaked or autonomous taxi has service standards mismatch or safety issues, then it can cause reputation and economic loss and increase the difficulty for the autonomous taxi to be accepted by the market. For example, several employees of Didi used their authority to check user travel records and make illegal profits [11]. Thus, blockchain-based anonymous ride-hailing services are of great significance to the development of RHS.In real life, there may be problems such as overloading of autonomous taxi to get more fees and mismatches in many service standards. This will cause safety issues and disputes between the rider and the platform. How to achieve transparent and credible management is a problem that the platform has been solving. In addition, autonomous taxi platforms may collect riders’ data. How to ensure the privacy of riders while providing services is also worthy of attention.In order to resolve the privacy issues between the rider and autonomous taxi, as well as disputes over autonomous service standards, we propose a blockchain-based anonymous ride-hailing scheme (BBARHS) for autonomous taxi network.


### 1.2. Related Works

Autonomous vehicles are one of the most anticipated technological developments of our time, and they have potential wide-ranging social influence [12]. However, there are serious privacy issues when users leak location information to the taxi server.In 2019, Yu et al. proposed a lightweight and privacy-preserving ride-matching scheme, called lpRide, to address the issue of protecting rider’s location privacy during ride matching [13]. In 2017, Zhang et al. used a third-party database and data interactive review platform to protect personal privacy. Online taxi service software platforms and other profit-making organizations can rent data interactive review platforms to announce to the public their improvements in personal privacy protection. However, this article does not provide a specific implementation and simulation of the system [11]. In 2018, Khazbak et al. proposed an enhanced solution that relies on enhanced driving matching and temporary stealth algorithms. The enhanced solution provides riders with personalized location privacy while limiting the loss of matching accuracy [14]. In 2017, Pham et al. proposed Private Ride, a practical solution that uses well-established privacy and cryptographic tools to enhance location privacy for the participants, while preserving the convenience and functionality offered by the current system [15]. In 2017, Pham et al. proposed ORide (Oblivious Ride), a privacy protection RHS based on somewhat-homomorphic encryption and with optimized functions such as ciphertext packaging and conversion processing, to address privacy issues in ride-hailing service [16].Many researchers have proposed different privacy-enhancing solutions for taxi service. However, according to our literature review, little work exists in the area of privacy and security for autonomous taxi network. Thus, we propose a blockchain-based anonymous ride-hailing service scheme in autonomous taxi network.Based on the summary of previous research, this study studied privacy and safety issues in autonomous taxi network. Our contributions are listed as follows:(1)
For the first time, we propose anonymous ride-hailing service for autonomous taxi network by making use of blockchain. We give a formal system model and security model. Our system can protect rider’s privacy and platform’s privacy simultaneously.(2)
The unlinkability between the payer address and the payee address is satisfied. Nontraceability is also satisfied. When the payment is executed, no one can find the relationship between them. No one can find the address of the payer.(3)
We first propose the blockchain-based anonymous ride-hailing service scheme (BBARHS). The proposed BBARHS scheme can be proved to be secure in the random oracle model. The analysis and the simulation show that the scheme is effective and practical for secure ride-hailing service of autonomous taxi network.


### 1.3. Organization

The rest is organized as follows: Section2gives some cryptographic background, which includes PKCs in PKI, blockchain, etc. The system model and the security model of the BBARHS scheme are introduced in Section 3. Our scheme is presented in Section 4. The analysis and the simulation are in Section 5. Finally, this study is concluded in Section 6.


## 1.1. Motivation

Security and privacy problems are the two major problems that need to be solved urgently for autonomous taxi network. In order to be able to provide services, the system needs to manage the location information of autonomous taxi, rider standards, service scenarios, how much fuel there is, and so on. After that, an autonomous taxi is allocated based on the service information requested by the rider. Finally, the rider needs to pay for the service. In these processes, how to protect the privacy of rider and how to ensure the safety of autonomous taxi are very important. If privacy of rider and autonomous taxi is leaked or autonomous taxi has service standards mismatch or safety issues, then it can cause reputation and economic loss and increase the difficulty for the autonomous taxi to be accepted by the market. For example, several employees of Didi used their authority to check user travel records and make illegal profits [11]. Thus, blockchain-based anonymous ride-hailing services are of great significance to the development of RHS.In real life, there may be problems such as overloading of autonomous taxi to get more fees and mismatches in many service standards. This will cause safety issues and disputes between the rider and the platform. How to achieve transparent and credible management is a problem that the platform has been solving. In addition, autonomous taxi platforms may collect riders’ data. How to ensure the privacy of riders while providing services is also worthy of attention.In order to resolve the privacy issues between the rider and autonomous taxi, as well as disputes over autonomous service standards, we propose a blockchain-based anonymous ride-hailing scheme (BBARHS) for autonomous taxi network.


## 1.2. Related Works

Autonomous vehicles are one of the most anticipated technological developments of our time, and they have potential wide-ranging social influence [12]. However, there are serious privacy issues when users leak location information to the taxi server.In 2019, Yu et al. proposed a lightweight and privacy-preserving ride-matching scheme, called lpRide, to address the issue of protecting rider’s location privacy during ride matching [13]. In 2017, Zhang et al. used a third-party database and data interactive review platform to protect personal privacy. Online taxi service software platforms and other profit-making organizations can rent data interactive review platforms to announce to the public their improvements in personal privacy protection. However, this article does not provide a specific implementation and simulation of the system [11]. In 2018, Khazbak et al. proposed an enhanced solution that relies on enhanced driving matching and temporary stealth algorithms. The enhanced solution provides riders with personalized location privacy while limiting the loss of matching accuracy [14]. In 2017, Pham et al. proposed Private Ride, a practical solution that uses well-established privacy and cryptographic tools to enhance location privacy for the participants, while preserving the convenience and functionality offered by the current system [15]. In 2017, Pham et al. proposed ORide (Oblivious Ride), a privacy protection RHS based on somewhat-homomorphic encryption and with optimized functions such as ciphertext packaging and conversion processing, to address privacy issues in ride-hailing service [16].Many researchers have proposed different privacy-enhancing solutions for taxi service. However, according to our literature review, little work exists in the area of privacy and security for autonomous taxi network. Thus, we propose a blockchain-based anonymous ride-hailing service scheme in autonomous taxi network.Based on the summary of previous research, this study studied privacy and safety issues in autonomous taxi network. Our contributions are listed as follows:(1)
For the first time, we propose anonymous ride-hailing service for autonomous taxi network by making use of blockchain. We give a formal system model and security model. Our system can protect rider’s privacy and platform’s privacy simultaneously.(2)
The unlinkability between the payer address and the payee address is satisfied. Nontraceability is also satisfied. When the payment is executed, no one can find the relationship between them. No one can find the address of the payer.(3)
We first propose the blockchain-based anonymous ride-hailing service scheme (BBARHS). The proposed BBARHS scheme can be proved to be secure in the random oracle model. The analysis and the simulation show that the scheme is effective and practical for secure ride-hailing service of autonomous taxi network.


## 1.3. Organization

The rest is organized as follows: Section2gives some cryptographic background, which includes PKCs in PKI, blockchain, etc. The system model and the security model of the BBARHS scheme are introduced in Section 3. Our scheme is presented in Section 4. The analysis and the simulation are in Section 5. Finally, this study is concluded in Section 6.


## 2. Background

This section will briefly explain the cryptographic background involved in the application of this article, the application of PKI and its PKCs and PKCs on the blockchain, ECC encryption algorithms and bilinear pairs, ring signatures, group signatures, and Monero.


### 2.1. PKCs on PKI and PKCs on Blockchain

PKCs are a set of public key cryptography standards developed by RSA data security company and its partners, which promote secure transaction and data transmission on the network, such as e-commerce and confidential mail [17]. It includes a series of related protocols, such as certificate application, certificate renewal, certificate revocation form release, certificate content extension, digital signature, and digital envelope format. PKC is a cryptosystem with a pair of keys, a widely spread public key and a private key known only by itself. The essence of blockchain is a decentralized database. It has no trusted third party. Therefore, there is no organization like CA (certificate authority) and PKI involved in the blockchain [18]. In the PKCs of blockchain, we use public key encryption to create a key pair to control the acquisition of assets. The key pair includes a private key and a unique public key derived from it. The public key corresponds to the address on the blockchain, in which the assets are stored, while the private key is used to sign transactions of the assets [19].


### 2.2. ECC and Bilinear Pairings

ECC (elliptic curve cryptosystem) is a public key cryptosystem with shorter key length than RSA. It is realized by special multiplication of a specific point on an elliptic curve. It takes advantage of the fact that the inverse operation of this multiplication operation is very difficult to achieve a good effect of encryption.Elliptic Curve on the Finite Field
F
q. For fixed a and b, all points x,y satisfying the shape of the equation y2≡x3+ax+bmodp,a,b,x,y∈Fq,4a3+27b2modp≠0 are set, plus a zero point and an infinite point 0, where a, b, x, and y are all take a value on the finite field Fq, that is, take a value on 0,1,2...p−1. P is a prime number.The discrete logarithm problem in the elliptic curve group refers to the problem of knowingP and Q in the group to solve the equation kP=Q in the value of k. It is easy to find Q from k and P, but it is difficult to find k from P and Q. This is the discrete logarithm problem on the elliptic curve, which can be applied to public key cryptosystems.In addition, the elliptic curve can be used to realize the Diffie–Hellman key exchange. By selecting a base fieldFq and two parameters a, b, the points on the elliptic curve and the infinity points form the Abel group Epa,b.Taking a generatorG=x1,y1 of Epa,b, the order of G is prime number n. Epa,b, G, and n are public parameters. User A and B start to exchange keys. A randomly selects an integer kA<n, keeps kA, calculates PA=kAG to generate E, and sends a point on a,b to B. B similarly selects the secret kB and calculates PB and sends it to A. A and B generate the shared secret key of both parties by K=kAPB and K=kBPA respectively, in fact K=kA,PB=kA,kBG=kB,kAG=kBPA. If the attacker wants to obtain K, then he must find kA from PA and G, or find kB from PB and G; that is, the discrete logarithm on the elliptic curve is required. Thus, it is not feasible.In 1983, Menezes et al. defined a special elliptic curve on a finite field, that is, a supersingular curve, and pointed out that these elliptic curves use the elliptic curve discrete logarithm problem to construct a more standard discrete logarithm of the cryptosystem [20]. The problem of using smaller finite fields does not exist. In the supersingular curve, there is an effective algorithm that maps two points on the curve (on a finite field) to an element in the base field. In the supersingular curve, the typical representatives are the Weil pair and Tate pair. These two supersingular elliptic curve pair transformations can be used to construct a bilinear pair. The basic concept of bilinear pairing is as follows:LetG1 and G2 be the additive group and multiplicative group of order q respectively and P is the generator of G1. Suppose that in the groups G1, G2, the discrete logarithm problem is difficult to solve. The bilinear mapping pair can be defined as e: G1×G1⟶G2 and meet the following characteristics:(1)
Bilinear. For all P, Q∈G1 and a,b∈Fp∗, eaP,bQ=eabP,Q=eP,abQ=eP,Qab.(2)
Nondegenerate. There is one P∈G1, which satisfies eP,P≠1.(3)
Computability. For P,Q∈G1, there is an effective algorithm to calculate eP,Q.A bilinear mape can be constructed using the modified Weil [21] or Tate pairings [22] on supersingular elliptic curve G1. A group G1 with such a map e is called a bilinear group, on which the CDHP is assumed hard, while the DDHP (decisional Diffie–Hellman problem) is easy [23]. Namely, given unknown a,b,c∈Fp∗ and P,aP,bP,cP∈G1, it is known that there exists an efficient algorithm to determine whether ab=cmodp by verifying eaP,bP=?eP,cP in polynomial time (DDHP), while there exist no efficient algorithms to compute abP∈G1 with non-negligible probability within polynomial time (CDHP).


### 2.3. Ring Signature, Aggregate Signature, and Monero Blockchain

Ring signature is a kind of digital signature scheme, which was first proposed by Kim [24]. Ring signature has only ring members, no manager and no cooperation between ring members. Ring signature refers to hiding the public key with private key among n public keys, which supports hiding transaction sender (address/public key) on blockchain. Suppose there are n users, and each user has a public key and its corresponding private key. Ring signature is a signature scheme, which can realize the signer’s unconditional anonymity, which is mainly composed of the following algorithms:(1)
Generate Gen. It is a probabilistic polynomial-time (PPT) algorithm. The input is security parameter K, and the output is public key and private key. It is assumed that Gen generates a public key and private key for each user, and the public and private keys of different users may come from different public key systems, such as RSA and DL.(2)
Sign. It is a PPT algorithm. After inputting the message m and the public key of n ring members L=y1,y2,…,yn and the private key information of one of the members, a signature R is generated for the message m. The parameters are in a ring shape according to certain rules.(3)
Verify. It is a deterministic algorithm. After inputting m,R, if R is the ring signature of M, then it will output “true”; otherwise, it will be “false.”Aggregate signature is a variant signature scheme used to aggregate any number of signatures into a single signature [25]. It can merge the public key and signature of each participant in a multisignature transaction into one public key and signature. The whole merging process is invisible, and the information before merging cannot be deduced from the combined public key and signature; only one verification is needed during verification. At present, the Schnorr signature algorithm is usually used to implement signature aggregation [26].Monero is a cryptocurrency for the connected world [27]. It is fast, private, and secure. Monero has the following three characteristics:(1)
Anonymity. Monero achieves anonymity by using ring confidential transactions (a combination of ring signature and anonymous transactions) and anonymous addresses. In addition, Kovri is used to confuse point-to-point communication. Due to the use of ring signature, at least six bait coins are added to each transaction, and each currency seems to be the actual amount spent in the transaction, making the actual source and target almost impossible to trace.(2)
Scalability. Due to the use of ring signature, each transaction is attached with additional data, which greatly increases the size of the blockchain. At the time of writing, the Monero blockchain is about 48 GB in size and will continue to grow with wider adoption, placing a burden on scalability. We estimate that the average transaction size in the Monero network is about 14 KB, almost 25 times the size of bitcoin. Simply put, when Monero reaches bitcoin’s current volume of transactions, its blockchain will be about 5 TB—almost unbearable for ordinary PCs, let alone on small devices. It is worth noting that the Monero team is currently implementing a bulletproof protocol that can increase scalability by up to 80 (still about five times that of bitcoin).(3)
Auditing. Monero provides the viewkey function to allow a third party to audit users’ transactions. However, it only allows you to view the input transactions, not the output transactions, making it less friendly to auditors. In addition, there seems to be no way to prove that the incoming transaction list is complete.


## 2.1. PKCs on PKI and PKCs on Blockchain

PKCs are a set of public key cryptography standards developed by RSA data security company and its partners, which promote secure transaction and data transmission on the network, such as e-commerce and confidential mail [17]. It includes a series of related protocols, such as certificate application, certificate renewal, certificate revocation form release, certificate content extension, digital signature, and digital envelope format. PKC is a cryptosystem with a pair of keys, a widely spread public key and a private key known only by itself. The essence of blockchain is a decentralized database. It has no trusted third party. Therefore, there is no organization like CA (certificate authority) and PKI involved in the blockchain [18]. In the PKCs of blockchain, we use public key encryption to create a key pair to control the acquisition of assets. The key pair includes a private key and a unique public key derived from it. The public key corresponds to the address on the blockchain, in which the assets are stored, while the private key is used to sign transactions of the assets [19].


## 2.2. ECC and Bilinear Pairings

ECC (elliptic curve cryptosystem) is a public key cryptosystem with shorter key length than RSA. It is realized by special multiplication of a specific point on an elliptic curve. It takes advantage of the fact that the inverse operation of this multiplication operation is very difficult to achieve a good effect of encryption.Elliptic Curve on the Finite Field
F
q. For fixed a and b, all points x,y satisfying the shape of the equation y2≡x3+ax+bmodp,a,b,x,y∈Fq,4a3+27b2modp≠0 are set, plus a zero point and an infinite point 0, where a, b, x, and y are all take a value on the finite field Fq, that is, take a value on 0,1,2...p−1. P is a prime number.The discrete logarithm problem in the elliptic curve group refers to the problem of knowingP and Q in the group to solve the equation kP=Q in the value of k. It is easy to find Q from k and P, but it is difficult to find k from P and Q. This is the discrete logarithm problem on the elliptic curve, which can be applied to public key cryptosystems.In addition, the elliptic curve can be used to realize the Diffie–Hellman key exchange. By selecting a base fieldFq and two parameters a, b, the points on the elliptic curve and the infinity points form the Abel group Epa,b.Taking a generatorG=x1,y1 of Epa,b, the order of G is prime number n. Epa,b, G, and n are public parameters. User A and B start to exchange keys. A randomly selects an integer kA<n, keeps kA, calculates PA=kAG to generate E, and sends a point on a,b to B. B similarly selects the secret kB and calculates PB and sends it to A. A and B generate the shared secret key of both parties by K=kAPB and K=kBPA respectively, in fact K=kA,PB=kA,kBG=kB,kAG=kBPA. If the attacker wants to obtain K, then he must find kA from PA and G, or find kB from PB and G; that is, the discrete logarithm on the elliptic curve is required. Thus, it is not feasible.In 1983, Menezes et al. defined a special elliptic curve on a finite field, that is, a supersingular curve, and pointed out that these elliptic curves use the elliptic curve discrete logarithm problem to construct a more standard discrete logarithm of the cryptosystem [20]. The problem of using smaller finite fields does not exist. In the supersingular curve, there is an effective algorithm that maps two points on the curve (on a finite field) to an element in the base field. In the supersingular curve, the typical representatives are the Weil pair and Tate pair. These two supersingular elliptic curve pair transformations can be used to construct a bilinear pair. The basic concept of bilinear pairing is as follows:LetG1 and G2 be the additive group and multiplicative group of order q respectively and P is the generator of G1. Suppose that in the groups G1, G2, the discrete logarithm problem is difficult to solve. The bilinear mapping pair can be defined as e: G1×G1⟶G2 and meet the following characteristics:(1)
Bilinear. For all P, Q∈G1 and a,b∈Fp∗, eaP,bQ=eabP,Q=eP,abQ=eP,Qab.(2)
Nondegenerate. There is one P∈G1, which satisfies eP,P≠1.(3)
Computability. For P,Q∈G1, there is an effective algorithm to calculate eP,Q.A bilinear mape can be constructed using the modified Weil [21] or Tate pairings [22] on supersingular elliptic curve G1. A group G1 with such a map e is called a bilinear group, on which the CDHP is assumed hard, while the DDHP (decisional Diffie–Hellman problem) is easy [23]. Namely, given unknown a,b,c∈Fp∗ and P,aP,bP,cP∈G1, it is known that there exists an efficient algorithm to determine whether ab=cmodp by verifying eaP,bP=?eP,cP in polynomial time (DDHP), while there exist no efficient algorithms to compute abP∈G1 with non-negligible probability within polynomial time (CDHP).


## 2.3. Ring Signature, Aggregate Signature, and Monero Blockchain

Ring signature is a kind of digital signature scheme, which was first proposed by Kim [24]. Ring signature has only ring members, no manager and no cooperation between ring members. Ring signature refers to hiding the public key with private key among n public keys, which supports hiding transaction sender (address/public key) on blockchain. Suppose there are n users, and each user has a public key and its corresponding private key. Ring signature is a signature scheme, which can realize the signer’s unconditional anonymity, which is mainly composed of the following algorithms:(1)
Generate Gen. It is a probabilistic polynomial-time (PPT) algorithm. The input is security parameter K, and the output is public key and private key. It is assumed that Gen generates a public key and private key for each user, and the public and private keys of different users may come from different public key systems, such as RSA and DL.(2)
Sign. It is a PPT algorithm. After inputting the message m and the public key of n ring members L=y1,y2,…,yn and the private key information of one of the members, a signature R is generated for the message m. The parameters are in a ring shape according to certain rules.(3)
Verify. It is a deterministic algorithm. After inputting m,R, if R is the ring signature of M, then it will output “true”; otherwise, it will be “false.”Aggregate signature is a variant signature scheme used to aggregate any number of signatures into a single signature [25]. It can merge the public key and signature of each participant in a multisignature transaction into one public key and signature. The whole merging process is invisible, and the information before merging cannot be deduced from the combined public key and signature; only one verification is needed during verification. At present, the Schnorr signature algorithm is usually used to implement signature aggregation [26].Monero is a cryptocurrency for the connected world [27]. It is fast, private, and secure. Monero has the following three characteristics:(1)
Anonymity. Monero achieves anonymity by using ring confidential transactions (a combination of ring signature and anonymous transactions) and anonymous addresses. In addition, Kovri is used to confuse point-to-point communication. Due to the use of ring signature, at least six bait coins are added to each transaction, and each currency seems to be the actual amount spent in the transaction, making the actual source and target almost impossible to trace.(2)
Scalability. Due to the use of ring signature, each transaction is attached with additional data, which greatly increases the size of the blockchain. At the time of writing, the Monero blockchain is about 48 GB in size and will continue to grow with wider adoption, placing a burden on scalability. We estimate that the average transaction size in the Monero network is about 14 KB, almost 25 times the size of bitcoin. Simply put, when Monero reaches bitcoin’s current volume of transactions, its blockchain will be about 5 TB—almost unbearable for ordinary PCs, let alone on small devices. It is worth noting that the Monero team is currently implementing a bulletproof protocol that can increase scalability by up to 80 (still about five times that of bitcoin).(3)
Auditing. Monero provides the viewkey function to allow a third party to audit users’ transactions. However, it only allows you to view the input transactions, not the output transactions, making it less friendly to auditors. In addition, there seems to be no way to prove that the incoming transaction list is complete.


## 3. System Model and Security Model

In this section, we describe the system model and security model for the BBARHS scheme. It contains the participating entities and the security requirements of the scheme.


### 3.1. System Model

In the BBARHS scheme for autonomous taxi network, there are four participating entities, namely, RHS, LAV (local autonomous vehicles), rider, and the blockchain. The detailed description is as follows:(1)
RHS. It is a ride-hiding service platform. It authorizes the legal riders and receives payment from riders. Considering management and performance bottlenecks, RHS does not provide direct services and LAVs added to autonomous taxi network.(2)
LAV. It is a local AVs provider. LAV provides ride-hiding service directly to local riders. When the ride-hiding service is completed, it sends the certificate to RHS and the receipt to the rider, respectively. Receipt and certificate are used to prove its service.(3)
Rider. Before requesting service, the rider needs to obtain RHS certification. Rider accepts LAV’s service and makes the payment through the blockchain.(4)
Blockchain. Rider and RHS have digital currency on the blockchain. Riders pay for service through the blockchain and RHS receives the digital coins sent by the rider.


### 3.2. Security Model

In the BARHS for autonomous taxi network, we consider four privacy issues. The privacy issues include the identity of the rider, payer address of the rider, payee address of RHS, and the unlinkability between payer address and payee address. In order to protect the above privacy, our BBARHS scheme must satisfy the following goals:(1)
Mutual Identification among Rider, RHS, and LAV. When the rider needs ride-hailing service, he must get the authorization from RHS. By verifying the validity of the authorization from RHS, LAV chooses whether to provide service. RHS and LAV interact to get the detailed information of rider.(2)
Anonymity for Rider. In the process of receiving LAV’s service, LAV cannot identify the identity of rider. In the process of authorization and payment, RHS cannot identify the identity of rider.(3)
Anonymity for RHS. Although RHS receives payment from the rider, RHS cannot identify rider’s address on the blockchain.(4)
Unlinkability between payer address (for the rider) and payee address (for RHS) on blockchain.This study uses many notations. These notations and the corresponding descriptions are listed in Table1.Table 1
Notations and descriptions.
Notations
Descriptions
E
Elliptic curve overFq for Monero
F
q
,
F
p
The finite field
F
q
∗
,
F
p
∗
The corresponding multiplicative groups ofFq,Fp
G
Base point ofE
l
^
Prime order ofG
H
1
,
H
2
Cryptographic hash functions
a
,
b
RHS’s random private key
A
,
B
RHS’s random public key
x
,
y
Rider’s private key on the blockchain
X
,
Y
Rider’s public key, which is also the rider’s address on the blockchain
G
1
,
G
2
Bilinear group pair
p
The prime order ofG1 and G2
e
Bilinear pairing
P A
Generator ofG1
z
,
Z
RHS’s private key/public key pair overG1 in PKI
l
j
,
L
j
LAV
j’s private key/public key pair over G1 in PKI
H
Full-domain cryptographic hash function
I
The set of rider’s index
J
The set of LAV’s index
m
i
,
j
The message that describes the service betweenrideri and LAVj
Tab
The table to record which riders are valid or invalid
Cont
i
,
σ
i
Authorization forRideri from RHS
m
i
,
j
,
A
i
,
B
i
σ
^
i
,
j
The receipt forRideri from LAVj and the certificate for RHS from LAVj
P
^
i
One-time public key for RHS, which is also RHS’s address on the blockchain
bal
i
The payment balance fromrideri
bal
c
The remaining change forrideri
P
i
The public key of the userUi, which is also Ui’s address on the blockchain
S
The cardinality of the setSAccording to the above security requirements, we give the formal security definitions as follows:Definition 1.
Unforgeability: RHS’s authentication protocol satisfies the unforgeability if the probability that A wins the following game is negligible where A is PPT (probabilistic polynomial time) adversary.(1)
Setup. The system parameters are created and RHS’s private/public key pair is generated. At the same time, rider’s private/public key pair is also generated. For RHS, its private/public key pair is generated in PKI (public key infrastructure). For the rider, its private/public key pairs are generated by the rider itself where there is no trusted third party. System parameters, RHS’s public key, and rider’s public key are sent to A. We denote the public parameters as params.(2)
Interaction between A and the Challenger C. In the interaction, A adaptively queries C and gets C’s responses. The queries and responses are listed as follows:(a)
Hash Query. A sends the hash queries to C. C creates the hash function value and sends it to A (random Oracle model). C accesses the hash function and responds A with the real hash value (standard model).(b)
Authentication Query. A makes the authentication query on the different public key with the corresponding message, which are denoted as Conti. C creates the authentication σi^ and sends it to A. In the process, we denote the query set as Conti^i^|∈I and the response set as σi^|i^∈I.(3)
Forgery. A can forge a valid authentication on a new public key with the corresponding message, which is denote as Cont. The forged public key and metadata are different from the queried public keys with the corresponding messages, that is, Cont∉Conti^i^|∈I.
We say that A wins the above game between A and C ifPrVerifyCont,params=“success”|Cont∉Conti^i^|∈I≥1/pk is a polynomial of the security parameter k. In other words, we say that A wins if A’s success probability is non-negligible.Note 1.
The above definition gives the formal definition of unforgeability for RHS authentication. For LAV authentication and ring signature for transaction, the formal definitions of their unforgeability are similar to the above definition. Due to the page limits, we omit the corresponding definitions.Definition 2.
Anonymity for the Rider: in the BBARHS scheme, RHS is unconditionally anonymous. In other words, the adversary cannot identify the rider’s real identity even if the adversary’s computing power is infinite.Definition 3.
Anonymity for RHS: when the rider hasn1 output addresses, if all the output addresses do not belong to the adversary, then the probability that RHS’s address can be identified is not more than 1/n1.Definition 4.
Untraceability: for each incoming transaction, all possible senders are equiprobable.Definition 5.
Unlinkability: for any two outgoing transactions, it is impossible to prove they were sent to the same person.


## 3.1. System Model

In the BBARHS scheme for autonomous taxi network, there are four participating entities, namely, RHS, LAV (local autonomous vehicles), rider, and the blockchain. The detailed description is as follows:(1)
RHS. It is a ride-hiding service platform. It authorizes the legal riders and receives payment from riders. Considering management and performance bottlenecks, RHS does not provide direct services and LAVs added to autonomous taxi network.(2)
LAV. It is a local AVs provider. LAV provides ride-hiding service directly to local riders. When the ride-hiding service is completed, it sends the certificate to RHS and the receipt to the rider, respectively. Receipt and certificate are used to prove its service.(3)
Rider. Before requesting service, the rider needs to obtain RHS certification. Rider accepts LAV’s service and makes the payment through the blockchain.(4)
Blockchain. Rider and RHS have digital currency on the blockchain. Riders pay for service through the blockchain and RHS receives the digital coins sent by the rider.


## 3.2. Security Model

In the BARHS for autonomous taxi network, we consider four privacy issues. The privacy issues include the identity of the rider, payer address of the rider, payee address of RHS, and the unlinkability between payer address and payee address. In order to protect the above privacy, our BBARHS scheme must satisfy the following goals:(1)
Mutual Identification among Rider, RHS, and LAV. When the rider needs ride-hailing service, he must get the authorization from RHS. By verifying the validity of the authorization from RHS, LAV chooses whether to provide service. RHS and LAV interact to get the detailed information of rider.(2)
Anonymity for Rider. In the process of receiving LAV’s service, LAV cannot identify the identity of rider. In the process of authorization and payment, RHS cannot identify the identity of rider.(3)
Anonymity for RHS. Although RHS receives payment from the rider, RHS cannot identify rider’s address on the blockchain.(4)
Unlinkability between payer address (for the rider) and payee address (for RHS) on blockchain.This study uses many notations. These notations and the corresponding descriptions are listed in Table1.Table 1
Notations and descriptions.
Notations
Descriptions
E
Elliptic curve overFq for Monero
F
q
,
F
p
The finite field
F
q
∗
,
F
p
∗
The corresponding multiplicative groups ofFq,Fp
G
Base point ofE
l
^
Prime order ofG
H
1
,
H
2
Cryptographic hash functions
a
,
b
RHS’s random private key
A
,
B
RHS’s random public key
x
,
y
Rider’s private key on the blockchain
X
,
Y
Rider’s public key, which is also the rider’s address on the blockchain
G
1
,
G
2
Bilinear group pair
p
The prime order ofG1 and G2
e
Bilinear pairing
P A
Generator ofG1
z
,
Z
RHS’s private key/public key pair overG1 in PKI
l
j
,
L
j
LAV
j’s private key/public key pair over G1 in PKI
H
Full-domain cryptographic hash function
I
The set of rider’s index
J
The set of LAV’s index
m
i
,
j
The message that describes the service betweenrideri and LAVj
Tab
The table to record which riders are valid or invalid
Cont
i
,
σ
i
Authorization forRideri from RHS
m
i
,
j
,
A
i
,
B
i
σ
^
i
,
j
The receipt forRideri from LAVj and the certificate for RHS from LAVj
P
^
i
One-time public key for RHS, which is also RHS’s address on the blockchain
bal
i
The payment balance fromrideri
bal
c
The remaining change forrideri
P
i
The public key of the userUi, which is also Ui’s address on the blockchain
S
The cardinality of the setSAccording to the above security requirements, we give the formal security definitions as follows:Definition 1.
Unforgeability: RHS’s authentication protocol satisfies the unforgeability if the probability that A wins the following game is negligible where A is PPT (probabilistic polynomial time) adversary.(1)
Setup. The system parameters are created and RHS’s private/public key pair is generated. At the same time, rider’s private/public key pair is also generated. For RHS, its private/public key pair is generated in PKI (public key infrastructure). For the rider, its private/public key pairs are generated by the rider itself where there is no trusted third party. System parameters, RHS’s public key, and rider’s public key are sent to A. We denote the public parameters as params.(2)
Interaction between A and the Challenger C. In the interaction, A adaptively queries C and gets C’s responses. The queries and responses are listed as follows:(a)
Hash Query. A sends the hash queries to C. C creates the hash function value and sends it to A (random Oracle model). C accesses the hash function and responds A with the real hash value (standard model).(b)
Authentication Query. A makes the authentication query on the different public key with the corresponding message, which are denoted as Conti. C creates the authentication σi^ and sends it to A. In the process, we denote the query set as Conti^i^|∈I and the response set as σi^|i^∈I.(3)
Forgery. A can forge a valid authentication on a new public key with the corresponding message, which is denote as Cont. The forged public key and metadata are different from the queried public keys with the corresponding messages, that is, Cont∉Conti^i^|∈I.
We say that A wins the above game between A and C ifPrVerifyCont,params=“success”|Cont∉Conti^i^|∈I≥1/pk is a polynomial of the security parameter k. In other words, we say that A wins if A’s success probability is non-negligible.Note 1.
The above definition gives the formal definition of unforgeability for RHS authentication. For LAV authentication and ring signature for transaction, the formal definitions of their unforgeability are similar to the above definition. Due to the page limits, we omit the corresponding definitions.Definition 2.
Anonymity for the Rider: in the BBARHS scheme, RHS is unconditionally anonymous. In other words, the adversary cannot identify the rider’s real identity even if the adversary’s computing power is infinite.Definition 3.
Anonymity for RHS: when the rider hasn1 output addresses, if all the output addresses do not belong to the adversary, then the probability that RHS’s address can be identified is not more than 1/n1.Definition 4.
Untraceability: for each incoming transaction, all possible senders are equiprobable.Definition 5.
Unlinkability: for any two outgoing transactions, it is impossible to prove they were sent to the same person.


## 4. An Efficient BBARHS Scheme

According to the system model and security model proposed in the previous section, we design a BBARHS scheme for autonomous taxi network. To satisfy the security model and transparent management, the proposed scheme takes use of some cryptographic techniques, which include PKI, digital signature, elliptic curve cryptography, and Monero. The proposed scheme consists of seven procedures: (i) initialization, (ii) contract-based authorization, (iii) anonymous service provision, (iv) pay for services, (v) verification and gain, (vi) solving the dispute, and (vii) rider revocation. The detailed procedures are given below.In order to show the intuition of the scheme, the structure of our scheme is shown in Figure2. There are four entities, that is, blockchain, RHS, LAV, and rider. We give the description of their interactions. (1) Riders and RHS generate the private key and public key respectively. The public key is the address on blockchain. RHS and LAVs also generate private key and public key pairs in PKI. (2) By making use of rider’s public key, the rider registers himself at RHS. (3) RHS has a table to record which riders are valid or invalid. RHS authorizes LAV to provide service for valid riders. (4) LAV provides service for the rider and sends the receipt to the rider. At the same time, LAV sends certificate to RHS. (5) Rider pays for the service through blockchain.Figure 2
Architecture of BBARHS scheme.


### 4.1. Initialization

In our proposed system, we use two types of system parameters. One type of parameter is used for blockchain. Other types of parameters are used for registration, receipt, certificate, authorization, and revocation. The detailed generated procedures are given below. Figure3 shows the process of contract-base authorization, anonymous service and receipt, pay for the service, and verification and gain.Figure 3
Sequence diagrams of BBARHS scheme.


### 4.2. Contract-Based Authorization

In order to get the service from LAV, theith rider, that is, rideri, needs RHS’s agreement. First, RHS needs to get rideri’s status information. Based on this information, the agreed contract Conti is created. Conti contains rider’s status information, pay for the service, service standards, etc. In order to protect rider’s privacy, Conti does not contains rider’s identity information. Xi is contained into Conti to get the authorization from RHS. At the same time, RHS records a table, which lists the valid rider. The authorization procedures are as follows:(1)
RHS generates the signatureσi for Conti below: σi=zHConti.(2)
RHS adds the addressX,Y into the table Tab.(3)
RHS sendsConti,σi to rider.(4)
RHS sends the updated tableTab to all the LAVs.


### 4.3. Anonymous Service and Receipt

Whenrideri accesses the anonymous taxi network and requests the service from RHS, it presents Conti,σi to the LAVj in the local area, where j∈J. LAVj’s private/public key pair is lj,Lj, where Lj=ljP. Conti,σi can be verified as follows:(1)
At some moment,LAVj receives a lot of pairs Conti,σi, where i∈I.(2)
For everyi∈I, LAVj extracts rideri’s public keys X,Y from Conti. If X,Y belongs to Tab, then LAVj provide service for rideri; otherwise, LAVj rejects rideri’s request.(3)
LAVj picks the random numbers αi∈Fp, i∈I and verifies whether the following formula holds:(1)e∑i∈Iαiσi,P=e∑i∈IαiHConti,Z.If the formula does not hold, thenLAVj finds out the invalid pairs and rejects them, and then go to the following procedure.(4)
Whenrideri receives service from LAVj, LAVj generates the receipt as follows:(a)
DenoteLAVj’s service information as the message mi,j. LAVj computes σ¯i,j=ljHmi,j,X,Y.(b)
LAVj sends mi,j,X,Y,σ¯i,j to RHS and rideri, respectively.Forrideri, mi,j,X,Y,σ¯i,j is the receipt for its service. For RHS, mi,j,X,Y,σ¯i,j is the certificate of the service for rideri.


### 4.4. Pay for the Service

Suppose that there are many LAVs. We denote them asLAVj,j∈J. For LAVj, the corresponding private/public key pair is lj,Lj, where Lj=ljP. RHS receives the certificate mi,j,A,B,σ¯i,j from LAGj, where i∈I,j∈J. RHS picks the random numbers βi,j∈Fp,i∈I,j∈J and verifies them by checking whether the following formula holds:(2)e∑j∈J,i∈Iβi,jσ¯i,j,P=∏j∈J,i∈Ieβi,jHmi,j,A,B,Lj.By checking the correctness of the above formula, RHS can determine whether the service is complete.In order to pay for the service,rideri performs the following procedures:(1)
For therideri where i∈I, rideri unpacks the received messages and gets RHS’s address A,B. Rideri generates a random number r∈Fl^∗, and then it gets a one-time public key P^i=H1rAG+B for RHS.(2)
For the messagesmi,j, where i∈I,j∈J, rideri can unpack it and get the balance bali,j to be paid. Suppose that rideri has the balance bal on the blockchain. Concretely, for RHS whose one-time public key (account address) is P^i, the output corresponds to the rewarding balance bali. Besides them, the additional output corresponds to the change balc=bal−bali. In order to simply the symbols, we denote the outputs and some metadata as the message m. For example, m contains R and P^i,bali for RHS, where R=rG.(3)
Rideri calculates A=H2Signtm where Signtm is the signature on the message m by making use of rideri’s private key t.(4)
Rideri selects a random subset S′ of the other users’ public key Pi, S′ has the cardinality n, and his own private/public key pair is xs,Ps, where 0≤s≤n. It also computes the image I=xsH2Ps. It picks the random numbers qi|i=0,1,…,n and wi|i=0,1,…,n,i≠s from Fl^∗. Then, it computes the following points:(3)Li=qiGifi=sqiG+wiPiifi≠s,Ri=qiH2Piifi=sqiH2Pi+wiIifi≠s..Then,rideri computes(4)c=H1m,A,L0,…,Ln,R0,…,Rn.The following values(5)ci=wiifi≠sc−∑i≠sciifi=s,ri=qiifi≠s.qs−csxsifi=s..The resulting signature is as follows:(6)σ=I,A,c0,…,cn,r0,…,rn.Whenrideri finished the above procedures, it sends the balance bali to P^i and balc to P^c with the signature σ, where P^c is selected by rideri. P^c is used to store the change balc.Note 2.
To avoid double-spending, the private key can be used only one time on the Monero. Thus, the changebalc must be moved to new address P^c, which is chosen by rideri on the Monero.


### 4.5. Verification and Gain

When RHS receives the signatureσ and the message m, RHS performs the following procedures to check the validity of the signature σ:(1)
RHS computesF2 in Table 2.(2)
RHS checks whetherF3 in Table 2 holds. If the formula does not hold, the signature is rejected.(3)
RHS checks whetherI has been used in past signatures. If it appeared in the past signatures, then the signature is rejected; otherwise, RHS accepts σ.Table 2
Formulas in Section4.
F
1
:
L
i
′
=
r
i
G
+
c
i
P
i
,
R
i
′
=
r
i
H
2
P
i
+
c
i
I
F
2
:
e
∑
j
∈
J
,
i
∈
I
β
i
,
j
σ
¯
i
,
j
,
P
=
∏
j
∈
J
,
i
∈
I
e
β
i
,
j
H
m
i
,
j
,
A
,
B
,
L
j
F
3
:
∑
i
=
0
n
c
i
=
H
1
m
,
A
,
L
0
′
,
…
,
L
n
′
mod
l
^In other words, the coinbali is moved to Pi^ and balc is moved to Pc^ from the address Ps.RHS checks rider’s paymentm,σ. From m, RHS extracts R and Pi^,bali where i∈I. RHS computes Pi′=H1aRG+Bi. If Pi′∈Pi^,i∈I, then there exists i^∈I, which satisfies Pi′=Pi^. In order to gain the reward li, RHS computes ki=H1aiR+bi, which satisfies Pi^=kiG. Thus, RHS gains the reward bali. Since RHS knows the private key of the address Pi^, RHS gains the reward bali.Notes. In the initialization procedure, RHS can generate a lots of account address, which are used for receiving coins from different transactions.


### 4.6. Solve the Dispute

When RHS cannot find itsbali, it sends its certification to rider. Rider checks RHS’s certification, and if it is valid, then rider tells RHS the transaction information with the ring signature. If RHS thinks rider is not the real signer, then rider performs the following procedure to prove he is the real signer:(1)
Rider shows RHS the preimageSigntm of the hash function H on the image A.(2)
RHS verifies whetherSigntm is the preimage of A and whether Signtm is a valid signature signed by rider’s public key T. If it is valid, then RHS admits that rider is the real signer; otherwise, RHS denies that rider is the real signer.


### 4.7. Rider Revocation

Rider revocation schemes from two cases are as follows:(1)
Case 1. When RHS wants to reject rider’s service, RHS updates the tableTab. RHS adds the revocation information to the table Tab and sends it to LAVs.(2)
Case 2. When the rider would like to be revoked, the rider can inform the revocation information to RHS. RHS updates the tableTab and sends it to LAVs.


## 4.1. Initialization

In our proposed system, we use two types of system parameters. One type of parameter is used for blockchain. Other types of parameters are used for registration, receipt, certificate, authorization, and revocation. The detailed generated procedures are given below. Figure3 shows the process of contract-base authorization, anonymous service and receipt, pay for the service, and verification and gain.Figure 3
Sequence diagrams of BBARHS scheme.


## 4.2. Contract-Based Authorization

In order to get the service from LAV, theith rider, that is, rideri, needs RHS’s agreement. First, RHS needs to get rideri’s status information. Based on this information, the agreed contract Conti is created. Conti contains rider’s status information, pay for the service, service standards, etc. In order to protect rider’s privacy, Conti does not contains rider’s identity information. Xi is contained into Conti to get the authorization from RHS. At the same time, RHS records a table, which lists the valid rider. The authorization procedures are as follows:(1)
RHS generates the signatureσi for Conti below: σi=zHConti.(2)
RHS adds the addressX,Y into the table Tab.(3)
RHS sendsConti,σi to rider.(4)
RHS sends the updated tableTab to all the LAVs.


## 4.3. Anonymous Service and Receipt

Whenrideri accesses the anonymous taxi network and requests the service from RHS, it presents Conti,σi to the LAVj in the local area, where j∈J. LAVj’s private/public key pair is lj,Lj, where Lj=ljP. Conti,σi can be verified as follows:(1)
At some moment,LAVj receives a lot of pairs Conti,σi, where i∈I.(2)
For everyi∈I, LAVj extracts rideri’s public keys X,Y from Conti. If X,Y belongs to Tab, then LAVj provide service for rideri; otherwise, LAVj rejects rideri’s request.(3)
LAVj picks the random numbers αi∈Fp, i∈I and verifies whether the following formula holds:(1)e∑i∈Iαiσi,P=e∑i∈IαiHConti,Z.If the formula does not hold, thenLAVj finds out the invalid pairs and rejects them, and then go to the following procedure.(4)
Whenrideri receives service from LAVj, LAVj generates the receipt as follows:(a)
DenoteLAVj’s service information as the message mi,j. LAVj computes σ¯i,j=ljHmi,j,X,Y.(b)
LAVj sends mi,j,X,Y,σ¯i,j to RHS and rideri, respectively.Forrideri, mi,j,X,Y,σ¯i,j is the receipt for its service. For RHS, mi,j,X,Y,σ¯i,j is the certificate of the service for rideri.


## 4.4. Pay for the Service

Suppose that there are many LAVs. We denote them asLAVj,j∈J. For LAVj, the corresponding private/public key pair is lj,Lj, where Lj=ljP. RHS receives the certificate mi,j,A,B,σ¯i,j from LAGj, where i∈I,j∈J. RHS picks the random numbers βi,j∈Fp,i∈I,j∈J and verifies them by checking whether the following formula holds:(2)e∑j∈J,i∈Iβi,jσ¯i,j,P=∏j∈J,i∈Ieβi,jHmi,j,A,B,Lj.By checking the correctness of the above formula, RHS can determine whether the service is complete.In order to pay for the service,rideri performs the following procedures:(1)
For therideri where i∈I, rideri unpacks the received messages and gets RHS’s address A,B. Rideri generates a random number r∈Fl^∗, and then it gets a one-time public key P^i=H1rAG+B for RHS.(2)
For the messagesmi,j, where i∈I,j∈J, rideri can unpack it and get the balance bali,j to be paid. Suppose that rideri has the balance bal on the blockchain. Concretely, for RHS whose one-time public key (account address) is P^i, the output corresponds to the rewarding balance bali. Besides them, the additional output corresponds to the change balc=bal−bali. In order to simply the symbols, we denote the outputs and some metadata as the message m. For example, m contains R and P^i,bali for RHS, where R=rG.(3)
Rideri calculates A=H2Signtm where Signtm is the signature on the message m by making use of rideri’s private key t.(4)
Rideri selects a random subset S′ of the other users’ public key Pi, S′ has the cardinality n, and his own private/public key pair is xs,Ps, where 0≤s≤n. It also computes the image I=xsH2Ps. It picks the random numbers qi|i=0,1,…,n and wi|i=0,1,…,n,i≠s from Fl^∗. Then, it computes the following points:(3)Li=qiGifi=sqiG+wiPiifi≠s,Ri=qiH2Piifi=sqiH2Pi+wiIifi≠s..Then,rideri computes(4)c=H1m,A,L0,…,Ln,R0,…,Rn.The following values(5)ci=wiifi≠sc−∑i≠sciifi=s,ri=qiifi≠s.qs−csxsifi=s..The resulting signature is as follows:(6)σ=I,A,c0,…,cn,r0,…,rn.Whenrideri finished the above procedures, it sends the balance bali to P^i and balc to P^c with the signature σ, where P^c is selected by rideri. P^c is used to store the change balc.Note 2.
To avoid double-spending, the private key can be used only one time on the Monero. Thus, the changebalc must be moved to new address P^c, which is chosen by rideri on the Monero.


## 4.5. Verification and Gain

When RHS receives the signatureσ and the message m, RHS performs the following procedures to check the validity of the signature σ:(1)
RHS computesF2 in Table 2.(2)
RHS checks whetherF3 in Table 2 holds. If the formula does not hold, the signature is rejected.(3)
RHS checks whetherI has been used in past signatures. If it appeared in the past signatures, then the signature is rejected; otherwise, RHS accepts σ.Table 2
Formulas in Section4.
F
1
:
L
i
′
=
r
i
G
+
c
i
P
i
,
R
i
′
=
r
i
H
2
P
i
+
c
i
I
F
2
:
e
∑
j
∈
J
,
i
∈
I
β
i
,
j
σ
¯
i
,
j
,
P
=
∏
j
∈
J
,
i
∈
I
e
β
i
,
j
H
m
i
,
j
,
A
,
B
,
L
j
F
3
:
∑
i
=
0
n
c
i
=
H
1
m
,
A
,
L
0
′
,
…
,
L
n
′
mod
l
^In other words, the coinbali is moved to Pi^ and balc is moved to Pc^ from the address Ps.RHS checks rider’s paymentm,σ. From m, RHS extracts R and Pi^,bali where i∈I. RHS computes Pi′=H1aRG+Bi. If Pi′∈Pi^,i∈I, then there exists i^∈I, which satisfies Pi′=Pi^. In order to gain the reward li, RHS computes ki=H1aiR+bi, which satisfies Pi^=kiG. Thus, RHS gains the reward bali. Since RHS knows the private key of the address Pi^, RHS gains the reward bali.Notes. In the initialization procedure, RHS can generate a lots of account address, which are used for receiving coins from different transactions.


## 4.6. Solve the Dispute

When RHS cannot find itsbali, it sends its certification to rider. Rider checks RHS’s certification, and if it is valid, then rider tells RHS the transaction information with the ring signature. If RHS thinks rider is not the real signer, then rider performs the following procedure to prove he is the real signer:(1)
Rider shows RHS the preimageSigntm of the hash function H on the image A.(2)
RHS verifies whetherSigntm is the preimage of A and whether Signtm is a valid signature signed by rider’s public key T. If it is valid, then RHS admits that rider is the real signer; otherwise, RHS denies that rider is the real signer.


## 4.7. Rider Revocation

Rider revocation schemes from two cases are as follows:(1)
Case 1. When RHS wants to reject rider’s service, RHS updates the tableTab. RHS adds the revocation information to the table Tab and sends it to LAVs.(2)
Case 2. When the rider would like to be revoked, the rider can inform the revocation information to RHS. RHS updates the tableTab and sends it to LAVs.


## 5. Security and Performance Analysis

The security and performance of our scheme are given in this section. According to security analysis, performance analysis, and the simulation result, our BBARS scheme is secure and practical.


### 5.1. Security Analysis

Theorem 1.
Authorization Correctness: if RHS and LAV are honest and follow the proposed BBARS scheme, then rider’s authorization from RHS can pass LAV’s verification.Proof.
According to the generation procedures ofrideri’s authorization, we get(1)
Correctness forrideri’s authorization:(7)e∑i∈Iαiσi,P=∏i∈Ieσi,Pαi,=∏i∈IezHConti,Pαi,=∏i∈IeαiHConti,zP,=e∑i∈IαiHConti,Z.(2)
Correctness forLAVj’s certificates:(8)e∑j∈J,i∈Iβi,jσ¯i,j,P=∏j∈J,i∈Ieβi,jσ¯i,j,P,=∏j∈J,i∈Ieβi,jljHmi,j,Xi,Yi,P,=∏j∈J,i∈Ieβi,jHmi,j,Xi,Yi,ljP,=∏j∈J,i∈Ieβi,jHmi,j,Xi,Yi,Lj.Theorem 2.
Verification Correctness: if the rider and RHS are honest and follow the proposed scheme, then rider’s signature can pass RHS’s verification.Proof.
From the generation process of rider’s signature, we get(1)
Wheni≠s, we get(9)Li′=riG+ciPi=qiG+ωiPi=Li.(10)Ri′=riH2Pi+ciI=qiH2Pi+ωiI=Ri.(2)
Wheni=s, we get(11)Ls′=rsG+csPs=qs−csxsG+csPs=qsG=Ls.(12)Rs′=rsH2Ps+csI,=qs−csxsH2Ps+csI,=qsH2Ps,=Rs.
Based on equations (1) and (2), we get(13)∑i=0nci=c=H1m,A,L0,L1,…,Ln,R0,R1,…,Rn=H1m,A,L0′,L1′,…,Ln′,R0′,R1′,…,Rn′modl^.Theorem 3.
Unforgeability: In our BBARHS scheme,rideri’s authorization from RHS, the receipt and certificate from LAV, and the ring signature from rider satisfy the unforgeability.Proof.
In our BBARHS scheme, we take use of BLS short signature scheme in PKI. BLS short signature scheme is provably secure, and the detailed proof process has been given in the reference. For the ring signature from rider, we take use of Saberhagen’s transaction scheme. The detailed proof process is similar to Saberhagen’s proof process, which can get in the reference. [28] Due to page limitations, we omit the proof process.Theorem 4.
Anonymity for Rider: in our BBARHS scheme, the rider is unconditionally anonymous. We prove this theorem from the following two parts:(1)
In the phase of contract-based authorization, rider’s contractConti does not include its identity information. The chosen public keys Xi,Yi have nothing to do with rideri’s identity. In the phase anonymous service and receipt, rideri submits Conti,σi to LAVj. The message does not include rideri’s identity. Thus, our BBARHS scheme does not need rideri’s identity. The scheme satisfies the anonymity for rider.(2)
Our phase pay for the service takes use of the ring signature to realize the anonymity of rider. From the final signatureσ=I,c0,…,cn,r0,…,cn, we know that I=xsH2Ps. On the other hand, both cs=H1m,A,L1,…,Ln,R1,…,Rn−∑i≠sci. Thus, if rider generates a transaction on behalf of a ring of n addresses, then rider’s anonymity can be satisfied.Theorem 5.
Anonymity for RHS: our BBARHS scheme satisfies anonymity for RHS.Proof.
When there aren1 output addresses and all the output addresses do not belong to the adversary, all the one-time public key P^i=H1rAiG+Bi is random due to the property of the hash function H1. Thus, all the n1 output addresses are random for the adversary.
In the following part, we show why our BBARHS scheme can satisfy the unlinkability and solve the dispute:(1)
From the phase pay for the service, the outgoing transaction addresses are one-time public keyP^i=H1rAG+B for RHS, where r∈Fl^∗. Thus, for any two outgoing transactions, it is impossible to prove they are sent to the same person.(2)
From the phase pay for the service, we know thatA=H2signtm. Based on the security properties of hash function H2, only rider know A’s preimage signtm. Thus, by showing Signtm, rider can prove he is the real signer. If RHS still does not believe rider is the real signer because A’s preimage may be come from others, then RHS verifies signtm by making use of rider’s public key T.(3)
If rider and RHS are honest and follow the above process, then they can resolve dispute.


### 5.2. Performance Analysis

Our BBARHS scheme must be efficient in terms of computation cost and communication cost. In our BBARHS scheme, two different PKCs are used: PKCs in PKI and PKCs on the blockchain. For PKCs on the blockchain, on the elliptic curveE, the point addition cost is denoted as CEadd and the scalar multiplication cost is denoted as CEmul. On the bilinear group pair G1,G2, the bilinear pairing cost is denoted as CBpair, the scalar multiplication cost is denoted as CBmul, and the point addition cost is denoted as CBadd. Comparing to the above computation cost, the other computation cost is smaller. For the above denotations, Emul is the abbreviation of scalar multiplication and Eadd is the abbreviation of point addition on E. On the other hand, Bpair is the abbreviation of bilinear pairing, Bmul is the abbreviation of scalar multiplication, and Badd is the abbreviation of point addition on G1,G2.


### 5.3. Theoretical Performance Analysis

For the performance of our scheme, the theoretical analysis is given in Table3. In Table 3, ∗ denotes the entity does not take part in the procedure. “Small” denotes the computation cost is less than the five operations CEmul, CEadd, CBpair, CBmul, and CBadd. n denotes the ring size of the ring signature. The procedure contract-based authorization is performed between the rider and RHS. Rider’s computation cost is small and RHS’s computation cost is ICBmul, where I is the number of riders. The procedure anonymous service and receipt is performed between rider and LAV. Rider’s computation cost is small and LAV’s computation cost is 2CBpair+3ICBmul+2I−1CBadd. The procedure pay for the service is performed by rider and RHS. Rider’s computation cost is 4N+4n−2CEmul+N+2n−2CEadd, where N is the number of services to be paid. N denotes the number of transactions needed to pay. RHS’s computation cost is N+1CBpair+2NCBmul+N−1CBadd. The procedure verification and gain is performed by RHS and blockchain. RHS’s computation cost is 3NCEmul+NCEadd and blockchain’s computation cost is 4nCEmul+2nCEadd.Table 3
Computation cost of the different entities.
Rider
LAV
RHS
Blockchain
Contract-based authorization
Small
∗
I
C
Bmul
∗
Anonymous service and receipt
Small
2
C
Bpair
+
3
I
C
Bmul
+
2
I
−
1
C
Badd
∗
∗
Pay for the service
4
N
+
4
n
−
2
C
Emul
+
N
+
2
n
−
2
C
Eadd
∗
N
+
1
C
Bpair
+
2
N
C
Bmul
+
N
−
1
C
Badd
∗
Verification
∗
∗
3
N
C
Emul
+
N
C
Eadd
4
n
C
Emul
+
2
n
C
EaddAccording to the above two PKCs, we analyze our BBARHS scheme’s communication cost, as listed in Table4. The PKC on the blockchain is the elliptic curve over the finite field Fq, where q=256 bits. In the bilinear group G1,G2, G1 is the supersingular elliptic curve over the finite field Fq^, where q^=512 bits. In the procedure contract-based optimization, rider sends Conti to RHS. RHS sends CRideri=Conti+σi=1024+Conti bits to Rideri and sends CLAV=Tab bits to LAV. σi’s size σi is a constant 1024. Conti is the size of the contract. At the same time, the communication cost of LAV only comes from the size Tab. Thus, CLAV has the linear relation with I. In the procedure anonymous service and receipt, LAVj sends mi,j,Xi,Yi,σ¯i,j to RHS and rideri, respectively. The corresponding communication cost is CLAVj=2mi,j+Xi+Yi+σi,j−=2mi,j+6144 bits. For the communication cost CLAVj, Xi, Yi, and σ¯i,j are the same constant, which are 1024 bits. On the other hand, mi,j has the linear relation with CLAVj. In the procedure pay for the service, the final signature size is Crider=σ=I+A+∑i=0nci+∑i=0nri=1024+506n bits for per service. For the communication cost Crider, the sizes of I, A, ci, and ri are different constants. They are 512 bits, 512 bits, 253 bits, and 253 bits, respectively. At last, CPayment has the linear relation with n, which is the number of the ring users.Table 4
Communication cost of the different entities (bits).
Procedure
Rider
LAV
RHS
Contract-based authorization
2
Cont
i
+
1024
Tab
2
Cont
i
+
Tab
+
1024
Anonymous service and receipt
m
i
,
j
+
3072
2
m
i
,
j
+
6144
m
i
,
j
+
3072
Pay for the service
1024
+
506
n
∗
∗
∗denotes the entity that does not take part in the procedure.


### 5.4. Implementation

In order to demonstrate our BBARHS scheme’s effectiveness, we implemented it by making use of the GMP (GMP-5.0.5), Miracl, and PBC (pbc-0.5.13) libraries. In our simulation, both RHS and LAV ran on a computer, which has the following features:(i)
CPU: Intel Core i5-8500 @ 3.0 GHz(ii)
Physical memory: 8 Gb(iii)
OS: Ubuntu 18.04Rider ran on a laptop, which has the following features:(i)
CPU: Intel Core i5-8500 @ 3.0 GHz(ii)
Physical memory: 8 Gb(iii)
OS: Ubuntu 18.04Besides the above simulation environment, we take use of the Monero blockchain. For the PKCs in PKI, we take use of the bilinear groupG1,G2, where G1 is defined on the finite field Fq^ with q^=512 bits. At the same time, G1 is a supersingular elliptic curve with 160 bits group order. Figure 4 depicts the time cost of RHS and LAV in the procedures contract-based authorization and anonymous service and receipt, respectively. In the figure, X-axis represents the number of riders. The Y-axis represents RHS and LAV’s computing time in ms (i.e., milliseconds). Because RHS authorizes rider independently, CAG’s time cost increases along with the increasing of rider number. On the other hand, LAV’s time cost increases fastly along with the increasing of rider number, which we can get the corroboration from Table 3. Figure 5 depicts the time cost of RHS in the procedure pay for the service. The Y-axis represents RHS’s computing time in ms (i.e., milliseconds). RHS’s time cost increases fastly along with the increasing of receipt number. TPS refers to the number of orders processed per second. In the procedure contract-based authorization, the average consumption time of RHS is about 10 ms and TPS is 100. RHS’s time cost in verifying receipt is about 8 ms and TPS is 125. LAG’s average consumption time in anonymous service and receipt is about 3 ms and TPS is 333. According to Uber’s published travel data for the third quarter of 2021, the number of orders processed per second was 206. The impact of performance is limited. The payment from the rider in the procedure pay for the service and the verification in the procedure verification are implemented by making use of Monero blockchain, which is effective and secure since 2014. Due to the page limits, we omit the corresponding simulation.Figure 4
RHS’s time cost in contract-based authorization and LAV’s time cost in anonymous service and receipt.Figure 5
RHS’s time cost in verifying receipt.


## 5.1. Security Analysis

Theorem 1.
Authorization Correctness: if RHS and LAV are honest and follow the proposed BBARS scheme, then rider’s authorization from RHS can pass LAV’s verification.Proof.
According to the generation procedures ofrideri’s authorization, we get(1)
Correctness forrideri’s authorization:(7)e∑i∈Iαiσi,P=∏i∈Ieσi,Pαi,=∏i∈IezHConti,Pαi,=∏i∈IeαiHConti,zP,=e∑i∈IαiHConti,Z.(2)
Correctness forLAVj’s certificates:(8)e∑j∈J,i∈Iβi,jσ¯i,j,P=∏j∈J,i∈Ieβi,jσ¯i,j,P,=∏j∈J,i∈Ieβi,jljHmi,j,Xi,Yi,P,=∏j∈J,i∈Ieβi,jHmi,j,Xi,Yi,ljP,=∏j∈J,i∈Ieβi,jHmi,j,Xi,Yi,Lj.Theorem 2.
Verification Correctness: if the rider and RHS are honest and follow the proposed scheme, then rider’s signature can pass RHS’s verification.Proof.
From the generation process of rider’s signature, we get(1)
Wheni≠s, we get(9)Li′=riG+ciPi=qiG+ωiPi=Li.(10)Ri′=riH2Pi+ciI=qiH2Pi+ωiI=Ri.(2)
Wheni=s, we get(11)Ls′=rsG+csPs=qs−csxsG+csPs=qsG=Ls.(12)Rs′=rsH2Ps+csI,=qs−csxsH2Ps+csI,=qsH2Ps,=Rs.
Based on equations (1) and (2), we get(13)∑i=0nci=c=H1m,A,L0,L1,…,Ln,R0,R1,…,Rn=H1m,A,L0′,L1′,…,Ln′,R0′,R1′,…,Rn′modl^.Theorem 3.
Unforgeability: In our BBARHS scheme,rideri’s authorization from RHS, the receipt and certificate from LAV, and the ring signature from rider satisfy the unforgeability.Proof.
In our BBARHS scheme, we take use of BLS short signature scheme in PKI. BLS short signature scheme is provably secure, and the detailed proof process has been given in the reference. For the ring signature from rider, we take use of Saberhagen’s transaction scheme. The detailed proof process is similar to Saberhagen’s proof process, which can get in the reference. [28] Due to page limitations, we omit the proof process.Theorem 4.
Anonymity for Rider: in our BBARHS scheme, the rider is unconditionally anonymous. We prove this theorem from the following two parts:(1)
In the phase of contract-based authorization, rider’s contractConti does not include its identity information. The chosen public keys Xi,Yi have nothing to do with rideri’s identity. In the phase anonymous service and receipt, rideri submits Conti,σi to LAVj. The message does not include rideri’s identity. Thus, our BBARHS scheme does not need rideri’s identity. The scheme satisfies the anonymity for rider.(2)
Our phase pay for the service takes use of the ring signature to realize the anonymity of rider. From the final signatureσ=I,c0,…,cn,r0,…,cn, we know that I=xsH2Ps. On the other hand, both cs=H1m,A,L1,…,Ln,R1,…,Rn−∑i≠sci. Thus, if rider generates a transaction on behalf of a ring of n addresses, then rider’s anonymity can be satisfied.Theorem 5.
Anonymity for RHS: our BBARHS scheme satisfies anonymity for RHS.Proof.
When there aren1 output addresses and all the output addresses do not belong to the adversary, all the one-time public key P^i=H1rAiG+Bi is random due to the property of the hash function H1. Thus, all the n1 output addresses are random for the adversary.
In the following part, we show why our BBARHS scheme can satisfy the unlinkability and solve the dispute:(1)
From the phase pay for the service, the outgoing transaction addresses are one-time public keyP^i=H1rAG+B for RHS, where r∈Fl^∗. Thus, for any two outgoing transactions, it is impossible to prove they are sent to the same person.(2)
From the phase pay for the service, we know thatA=H2signtm. Based on the security properties of hash function H2, only rider know A’s preimage signtm. Thus, by showing Signtm, rider can prove he is the real signer. If RHS still does not believe rider is the real signer because A’s preimage may be come from others, then RHS verifies signtm by making use of rider’s public key T.(3)
If rider and RHS are honest and follow the above process, then they can resolve dispute.


## 5.2. Performance Analysis

Our BBARHS scheme must be efficient in terms of computation cost and communication cost. In our BBARHS scheme, two different PKCs are used: PKCs in PKI and PKCs on the blockchain. For PKCs on the blockchain, on the elliptic curveE, the point addition cost is denoted as CEadd and the scalar multiplication cost is denoted as CEmul. On the bilinear group pair G1,G2, the bilinear pairing cost is denoted as CBpair, the scalar multiplication cost is denoted as CBmul, and the point addition cost is denoted as CBadd. Comparing to the above computation cost, the other computation cost is smaller. For the above denotations, Emul is the abbreviation of scalar multiplication and Eadd is the abbreviation of point addition on E. On the other hand, Bpair is the abbreviation of bilinear pairing, Bmul is the abbreviation of scalar multiplication, and Badd is the abbreviation of point addition on G1,G2.


## 5.3. Theoretical Performance Analysis

For the performance of our scheme, the theoretical analysis is given in Table3. In Table 3, ∗ denotes the entity does not take part in the procedure. “Small” denotes the computation cost is less than the five operations CEmul, CEadd, CBpair, CBmul, and CBadd. n denotes the ring size of the ring signature. The procedure contract-based authorization is performed between the rider and RHS. Rider’s computation cost is small and RHS’s computation cost is ICBmul, where I is the number of riders. The procedure anonymous service and receipt is performed between rider and LAV. Rider’s computation cost is small and LAV’s computation cost is 2CBpair+3ICBmul+2I−1CBadd. The procedure pay for the service is performed by rider and RHS. Rider’s computation cost is 4N+4n−2CEmul+N+2n−2CEadd, where N is the number of services to be paid. N denotes the number of transactions needed to pay. RHS’s computation cost is N+1CBpair+2NCBmul+N−1CBadd. The procedure verification and gain is performed by RHS and blockchain. RHS’s computation cost is 3NCEmul+NCEadd and blockchain’s computation cost is 4nCEmul+2nCEadd.Table 3
Computation cost of the different entities.
Rider
LAV
RHS
Blockchain
Contract-based authorization
Small
∗
I
C
Bmul
∗
Anonymous service and receipt
Small
2
C
Bpair
+
3
I
C
Bmul
+
2
I
−
1
C
Badd
∗
∗
Pay for the service
4
N
+
4
n
−
2
C
Emul
+
N
+
2
n
−
2
C
Eadd
∗
N
+
1
C
Bpair
+
2
N
C
Bmul
+
N
−
1
C
Badd
∗
Verification
∗
∗
3
N
C
Emul
+
N
C
Eadd
4
n
C
Emul
+
2
n
C
EaddAccording to the above two PKCs, we analyze our BBARHS scheme’s communication cost, as listed in Table4. The PKC on the blockchain is the elliptic curve over the finite field Fq, where q=256 bits. In the bilinear group G1,G2, G1 is the supersingular elliptic curve over the finite field Fq^, where q^=512 bits. In the procedure contract-based optimization, rider sends Conti to RHS. RHS sends CRideri=Conti+σi=1024+Conti bits to Rideri and sends CLAV=Tab bits to LAV. σi’s size σi is a constant 1024. Conti is the size of the contract. At the same time, the communication cost of LAV only comes from the size Tab. Thus, CLAV has the linear relation with I. In the procedure anonymous service and receipt, LAVj sends mi,j,Xi,Yi,σ¯i,j to RHS and rideri, respectively. The corresponding communication cost is CLAVj=2mi,j+Xi+Yi+σi,j−=2mi,j+6144 bits. For the communication cost CLAVj, Xi, Yi, and σ¯i,j are the same constant, which are 1024 bits. On the other hand, mi,j has the linear relation with CLAVj. In the procedure pay for the service, the final signature size is Crider=σ=I+A+∑i=0nci+∑i=0nri=1024+506n bits for per service. For the communication cost Crider, the sizes of I, A, ci, and ri are different constants. They are 512 bits, 512 bits, 253 bits, and 253 bits, respectively. At last, CPayment has the linear relation with n, which is the number of the ring users.Table 4
Communication cost of the different entities (bits).
Procedure
Rider
LAV
RHS
Contract-based authorization
2
Cont
i
+
1024
Tab
2
Cont
i
+
Tab
+
1024
Anonymous service and receipt
m
i
,
j
+
3072
2
m
i
,
j
+
6144
m
i
,
j
+
3072
Pay for the service
1024
+
506
n
∗
∗
∗denotes the entity that does not take part in the procedure.


## 5.4. Implementation

In order to demonstrate our BBARHS scheme’s effectiveness, we implemented it by making use of the GMP (GMP-5.0.5), Miracl, and PBC (pbc-0.5.13) libraries. In our simulation, both RHS and LAV ran on a computer, which has the following features:(i)
CPU: Intel Core i5-8500 @ 3.0 GHz(ii)
Physical memory: 8 Gb(iii)
OS: Ubuntu 18.04Rider ran on a laptop, which has the following features:(i)
CPU: Intel Core i5-8500 @ 3.0 GHz(ii)
Physical memory: 8 Gb(iii)
OS: Ubuntu 18.04Besides the above simulation environment, we take use of the Monero blockchain. For the PKCs in PKI, we take use of the bilinear groupG1,G2, where G1 is defined on the finite field Fq^ with q^=512 bits. At the same time, G1 is a supersingular elliptic curve with 160 bits group order. Figure 4 depicts the time cost of RHS and LAV in the procedures contract-based authorization and anonymous service and receipt, respectively. In the figure, X-axis represents the number of riders. The Y-axis represents RHS and LAV’s computing time in ms (i.e., milliseconds). Because RHS authorizes rider independently, CAG’s time cost increases along with the increasing of rider number. On the other hand, LAV’s time cost increases fastly along with the increasing of rider number, which we can get the corroboration from Table 3. Figure 5 depicts the time cost of RHS in the procedure pay for the service. The Y-axis represents RHS’s computing time in ms (i.e., milliseconds). RHS’s time cost increases fastly along with the increasing of receipt number. TPS refers to the number of orders processed per second. In the procedure contract-based authorization, the average consumption time of RHS is about 10 ms and TPS is 100. RHS’s time cost in verifying receipt is about 8 ms and TPS is 125. LAG’s average consumption time in anonymous service and receipt is about 3 ms and TPS is 333. According to Uber’s published travel data for the third quarter of 2021, the number of orders processed per second was 206. The impact of performance is limited. The payment from the rider in the procedure pay for the service and the verification in the procedure verification are implemented by making use of Monero blockchain, which is effective and secure since 2014. Due to the page limits, we omit the corresponding simulation.Figure 4
RHS’s time cost in contract-based authorization and LAV’s time cost in anonymous service and receipt.Figure 5
RHS’s time cost in verifying receipt.


## 6. Conclusion

In this study, we studied the privacy protection and anonymous ride-hailing service for autonomous taxi networks. By taking use of blockchain, we present the security and privacy threats and first proposed blockchain-based anonymous ride-hailing scheme for autonomous taxi network. We give the formal system model and security model. Based on the aggregated signature, ring signature, and Monero, we design the first BBARHS scheme. The analysis and implementation show that our BBARHS scheme is provably secure and practical.In the future, we will further study the system model and security model for different application scenarios, for example, how to solve the privacy threats in multiperson carpooling.



---

*Source: 8296608-2022-08-09.xml*