BBARHS:Blockchain-BasedAnonymousRide-Hailing Scheme for Autonomous Taxi Network

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. )en, we outline the concrete BBARHS scheme by making use of Monero and some efficient crypto tools. )rough security analysis and performance analysis, the designed scheme is provably secure and efficient. )e analysis results also show the designed BBARHS scheme is practical for autonomous taxi network.


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][8][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. e blockchain contains a certain and verifiable record of every single transaction ever made [10]. e basic structure of blockchain is shown in Figure 1.
e 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. e ECDSA is an analog of the digital signature algorithm (DSA) using elliptic curve cryptography (ECC). e 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. e 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. at 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 with N 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. is article aims to use the characteristics of blockchain technology to solve these problems in the field of autonomous taxi.

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]. us, 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. is 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.

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 privacypreserving 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. e 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 somewhathomomorphic 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. us, 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 ridehailing 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) e 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 ridehailing service scheme (BBARHS). e proposed BBARHS scheme can be proved to be secure in the random oracle model. e analysis and the simulation show that the scheme is effective and practical for secure ride-hailing service of autonomous taxi network.

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

Background
is 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.

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. e essence of blockchain is a decentralized database. It has no trusted third party. erefore, 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.
e key pair includes a private key and a unique public key derived from it. e 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].

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 y 2 ≡ x 3 + ax + b(modp), (a, b, x, y ∈ F q , 4a 3 + 27b 2 (modp) ≠ 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 F q , that is, take a value on 0, 1, 2...p − 1. P is a prime number. e discrete logarithm problem in the elliptic curve group refers to the problem of knowing P 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.
is 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 field F q and two parameters a, b, the points on the elliptic curve and the infinity points form the Abel group E p (a, b).
Taking a generator G � ( ), the order of G is prime number n. E p (a, b), G, and n are public parameters. User A and B start to exchange keys. A randomly selects an integer k A < n, keeps k A , calculates P A � k A G to generate E, and sends a point on (a, b) to B. B similarly selects the secret k B and calculates P B and sends it to A. A and B generate the shared secret key of both parties by K � k A P B and If the attacker wants to obtain K, then he must find k A from P A and G, or find k B from P B and G; that is, the discrete logarithm on the elliptic curve is required. us, 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 Security and Communication Networks logarithm problem to construct a more standard discrete logarithm of the cryptosystem [20]. e 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. ese two supersingular elliptic curve pair transformations can be used to construct a bilinear pair. e basic concept of bilinear pairing is as follows: Let G 1 and G 2 be the additive group and multiplicative group of order q respectively and P is the generator of G 1 . Suppose that in the groups G 1 , G 2 , the discrete logarithm problem is difficult to solve. e bilinear mapping pair can be defined as e: G 1 × G 1 ⟶ G 2 and meet the following characteristics: (1) Bilinear. For all P, Q ∈ G 1 and a, b ∈ F * p , e(aP, bQ) � e(abP, Q) � e(P, abQ) � e(P, Q) ab .
(3) Computability. For P, Q ∈ G 1 , there is an effective algorithm to calculate e(P, Q).
A bilinear map e can be constructed using the modified Weil [21] or Tate pairings [22] on supersingular elliptic curve G 1 . A group G 1 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 ∈ F * p and P, aP, bP, cP ∈ G 1 , it is known that there exists an efficient algorithm to determine whether ab � cmodp by verifying e(aP, bP)� ? e(P, cP) in polynomial time (DDHP), while there exist no efficient algorithms to compute abP ∈ G 1 with non-negligible probability within polynomial time (CDHP).

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. e 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 � y 1 , y 2 , . . . , y n and the private key information of one of the members, a signature R is generated for the message m. e 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. e 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.

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.

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. e 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 ridehiding service directly to local riders. When the ridehiding 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.

Security Model.
In the BARHS for autonomous taxi network, we consider four privacy issues. e 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. (4) Unlinkability between payer address (for the rider) and payee address (for RHS) on blockchain.
is study uses many notations. ese notations and the corresponding descriptions are listed in Table 1.
According 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. e 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. public key with the corresponding message, which is denote as Cont. e forged public key and metadata are different from the queried public keys with the corresponding messages, that is, Cont ∉ Cont i i| ∈ I . We say that A wins the above game between A and C if Pr[Verify(Cont, params) � "success"|Cont ∉ Cont i i| ∈ I ] ≥ (1/p(k)) is a polynomial of the security parameter k. In other words, we say that A wins if A's success probability is non-negligible.

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. e 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. e detailed procedures are given below.
In order to show the intuition of the scheme, the structure of our scheme is shown in Figure 2. ere 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. e 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.

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. e detailed generated procedures are given below. Figure 3 shows the process of contract-base authorization, anonymous service and receipt, pay for the service, and verification and gain.

Contract-Based Authorization.
In order to get the service from LAV, the ith rider, that is, rider i , needs RHS's agreement. First, RHS needs to get rider i 's status information. Based on this information, the agreed contract Cont i is created. Cont i contains rider's status information, pay for

Anonymous Service and Receipt.
When rider i accesses the anonymous taxi network and requests the service from RHS, it presents (Cont i , σ i ) to the LAV j in the local area, where j ∈ J. LAV j 's private/public key pair is (l j , L j ), where L j � l j P. (Cont i , σ i ) can be verified as follows: (1) At some moment, LAV j receives a lot of pairs (Cont i , σ i ), where i ∈ I. (2) For every i ∈ I, LAV j extracts rider i 's public keys (X, Y) from Cont i . If (X, Y) belongs to Tab, then LAV j provide service for rider i ; otherwise, LAV j rejects rider i 's request. (3) LAV j picks the random numbers α i ∈ F p , i ∈ I and verifies whether the following formula holds:

Security and Communication Networks
If the formula does not hold, then LAV j finds out the invalid pairs and rejects them, and then go to the following procedure. (4) When rider i receives service from LAV j , LAV j generates the receipt as follows: (a) Denote LAV j 's service information as the message (m i,j , X, Y, σ i,j ) to RHS and rider i , respectively.
For rider i , (m i,j , X, Y, σ i,j ) is the receipt for its service. For RHS, (m i,j , X, Y, σ i,j ) is the certificate of the service for rider i .

Pay for the Service.
Suppose that there are many LAVs. We denote them as LAV j , j ∈ J. For LAV j , the corresponding private/public key pair is (l j , L j ), where L j � l j P. RHS receives the certificate (m i,j , A, B, σ i,j ) from LAG j , where i ∈ I, j ∈ J. RHS picks the random numbers β i,j ∈ F p , i ∈ I, j ∈ J and verifies them by checking whether the following formula holds: e j∈J,i∈I By checking the correctness of the above formula, RHS can determine whether the service is complete.
In order to pay for the service, rider i performs the following procedures: (1) For the rider i where i ∈ I, rider i unpacks the received messages and gets RHS's address (A, B). Rider i generates a random number r ∈ F * l , and then it gets a one-time public key P i � H 1 (rA)G + B for RHS.
(2) For the messages m i,j , where i ∈ I, j ∈ J, rider i can unpack it and get the balance bal i,j to be paid. Suppose that rider i 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 bal i . Besides them, the additional output corresponds to the change bal c � bal − bal i . In order to simply the symbols, we denote the outputs and some metadata as the message m. For example, m contains R and is the signature on the message m by making use of rider i 's private key t.
(4) Rider i selects a random subset S ′ of the other users' public key P i , S ′ has the cardinality n, and his own private/public key pair is (x s , P s ), where 0 ≤ s ≤ n. It also computes the image I � x s H 2 (Ps). It picks the random numbers q i |i � 0, 1, . . . , n and w i |i � 0, 1, . . . , n, i ≠ s from F * l . en, it computes the following points: e following values e resulting signature is as follows: σ � I, A, c 0 , . . . , c n , r 0 , . . . , r n .
When rider i finished the above procedures, it sends the balance bal i to P i and bal c to P c with the signature σ, where P c is selected by rider i . P c is used to store the change bal c .

Note 2.
To avoid double-spending, the private key can be used only one time on the Monero. us, the change bal c must be moved to new address P c , which is chosen by rider i on the Monero.

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 computes F2 in Table 2.
(2) RHS checks whether F3 in Table 2 holds. If the formula does not hold, the signature is rejected. (3) RHS checks whether I has been used in past signatures. If it appeared in the past signatures, then the signature is rejected; otherwise, RHS accepts σ.
In other words, the coin bal i is moved to P i and bal c is moved to P c from the address P s . RHS checks rider's payment (m, σ). From m, RHS extracts R and (P i , bal i ) where i ∈ I. RHS computes P i ′ � H 1 (aR)G + B i . If P i ′ ∈P i , i ∈ I, then there exists i∈ I, which satisfies P i ′ � P i . In order to gain the reward l i , RHS computes k i � H 1 (a i R) + b i , which satisfies P i � k i G. us, RHS gains the reward bal i . Since RHS knows the private key of the address P i , RHS gains the reward bal i . 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 its bal i , 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 preimage Sign t (m) of the hash function H on the image A. (2) RHS verifies whether Sign t (m) is the preimage of A and whether Sign t (m) 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.

Rider Revocation.
Rider revocation schemes from two cases are as follows: (

Security and Performance Analysis
e 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.

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 of rider i 's authorization, we get (1) Correctness for rider i 's authorization: (2) Correctness for LAV j 's certificates: e j∈J,i∈I (2) When i � s, we get Based on equations (1) and (2)  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. e 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. Proof. When there are n 1 output addresses and all the output addresses do not belong to the adversary, all the onetime public key P i � H 1 (rA i )G + B i is random due to the property of the hash function H 1 . us, all the n 1 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 key P i � H 1 (rA)G + B for RHS, where r ∈ F * l . us, 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 that A � H 2 (sign t (m)). Based on the security properties of hash function H 2 , only rider know A's preimage sign t (m). us, by showing Sign t (m), 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 sign t (m) 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.

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 curve E, the point addition cost is denoted as C Eadd and the scalar multiplication cost is denoted as C Emul . On the bilinear group pair (G 1 , G 2 ), the bilinear pairing cost is denoted as C Bpair , the scalar multiplication cost is denoted as C Bmul , and the point addition cost is denoted as C Badd . Comparing to the above computation cost, the other computation cost is smaller. For the above denotations, E mul is the abbreviation of scalar multiplication and E add is the abbreviation of point addition on E. On the other hand, B pair is the abbreviation of bilinear pairing, B mul is the abbreviation of scalar multiplication, and B add is the abbreviation of point addition on (G 1 , G 2 ).

eoretical Performance Analysis.
For the performance of our scheme, the theoretical analysis is given in Table 3. In Table 3, * denotes the entity does not take part in the procedure. "Small" denotes the computation cost is less than the five operations C Emul , C Eadd , C Bpair , C Bmul , and C Badd . n denotes the ring size of the ring signature. e procedure contract-based authorization is performed between the rider and RHS. Rider's computation cost is small and RHS's computation cost is |I|C Bmul , where |I| is the number of riders. e procedure anonymous service and receipt is performed between rider and LAV. Rider's computation cost is small and LAV's computation cost is 2C Bpair + 3|I|C Bmul + 2(|I| − 1)C Badd . e procedure pay for the service is performed by rider and RHS. Rider's computation cost is (4N + 4n − 2)C Emul + (N + 2n − 2)C Eadd , 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 + 1)C Bpair + 2NC Bmul + (N − 1)C Badd . e procedure verification and gain is performed by RHS and blockchain. RHS's computation cost is 3NC Emul + NC Eadd and blockchain's computation cost is 4nC Emul + 2nC Eadd .
According to the above two PKCs, we analyze our BBARHS scheme's communication cost, as listed in Table 4. e PKC on the blockchain is the elliptic curve over the finite field F q , where |q| � 256 bits. In the bilinear group (G 1 , G 2 ), G 1 is the supersingular elliptic curve over the finite field F q , where |q| � 512 bits. In the procedure contract-based optimization, rider sends |Cont i | to RHS. RHS sends C Rider i � |Cont i | + |σ i | � 1024 + |Cont i | bits to Rider i and sends C LAV � |Tab| bits to LAV. σ i 's size |σ i | is a constant 1024. |Cont i | is the size of the contract. At the same time, the communication cost of LAV only comes from the size |Tab|.
us, C LAV has the linear relation with |I|. In the procedure anonymous service and receipt, LAV j sends (m i,j , X i , Y i , σ i,j ) to RHS and rider i , respectively. e corresponding communication cost is C LAV j � 2(|m i,j | + |X i | + |Y i | + |σ − i,j |) � 2|m i,j | + 6144 bits. For the communication cost C LAV j , |X i |, |Y i |, and σ i,j are the same constant, which are 1024 bits. On the other hand, |m i,j | has the linear relation with C LAV j . In the procedure pay for the service, the final signature size is C rider � |σ| � |I| + |A| + n i�0 |c i | + n i�0 |r i | � 1024 + 506n bits for per service. For the communication cost C rider , the sizes of I, A, c i , and r i are different constants. ey are 512 bits, 512 bits, 253 bits, and 253 bits, respectively. At last, C Payment has the linear relation with n, which is the number of the ring users.

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: Rider 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.04 Besides the above simulation environment, we take use of the Monero blockchain. For the PKCs in PKI, we take use of the bilinear group (G 1 , G 2 ), where G 1 is defined on the finite field F q with |q| � 512 bits. At the same time, G 1 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. e 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.
e 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. e impact of performance is limited. e 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.

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. e 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.

Data Availability
e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that they have no conflicts of interest.