Source-linked AI summary
B-Ride: Ride Sharing with Privacy-preservation, Trust and Fair Payment atop Public Blockchain
Mohamed Baza, Noureddine Lasla, Mohamed Mahmoud, Gautam Srivastava, Mohamed Abdallah
TL;DR
Existing ride-sharing platforms depend on centralized intermediaries that expose users to failure, privacy, and fee concerns. B-Ride addresses these issues with a permissionless-blockchain service using cloaking, smart contracts, zero-knowledge deposits, distance-based payment, and reputation management. Experiments on an Ethereum test net indicate that the system is practical in terms of on-chain and off-chain overheads.
Problem
Centralized ride-sharing platforms create single-point-of-failure, privacy-disclosure, and high-fee concerns, while public-blockchain anonymity can enable uncommitted ride requests or offers.
Method
B-Ride combines permissionless blockchain smart contracts with cloaked trip data, zero-knowledge set membership, time-locked deposits, pay-as-you-drive payment, and driver reputation management.
Results
B-Ride is practical in terms of on-chain and off-chain overheads and addresses the transparency–privacy and accountability–anonymity objectives of decentralized ride sharing.
Takeaways & Limitations
A public-blockchain ride-sharing service can combine privacy preservation, user accountability, and decentralized execution within the proposed B-Ride design.
Takeaways & Limitations
New drivers may lack reputation scores, so riders can select drivers without an established reputation history.
Abstract
from arXiv · showhide
Ride-sharing is a service that enables drivers to share their trips with other riders, contributing to appealing benefits of shared travel costs. However, the majority of existing platforms rely on a central third party, which make them subject to a single point of failure and privacy disclosure issues. Moreover, they are vulnerable to DDoS and Sybil attacks due to malicious users involvement. Besides, high fees should be paid to the service provider. In this paper, we propose a decentralized ride-sharing service based on public Blockchain, named B-Ride. Both riders and drivers can find rides match while preserving their trip data, including pick-up/drop-off location, and departure/arrival date. However, under the anonymity of the public blockchain, a malicious user may submit multiple ride requests or offers, while not committing to any of them, to discover better offer or to make the system unreliable. B-Ride solves this problem by introducing a time-locked deposit protocol for a ride-sharing by leveraging smart contract and zero-knowledge set membership proof. In a nutshell, both a driver and a rider have to show their commitment by sending a deposit to the blockchain. Later, a driver has to prove to the blockchain on the agreed departure time that he has arrived at the pick-up location. To preserve rider/driver location privacy by hiding the exact pick-up location, the proof is done using zero-knowledge set membership protocol. Moreover, to ensure a fair payment, a pay-as-you-drive methodology is introduced based on the elapsed distance of the driver and the rider. Also, we introduce a reputation-based trust model to rate drivers based on their past trips to allow riders to select them based on their history on the system. Finally, we implement B-Ride in a test net of Ethereum. The experiment results show the applicability of our protocol atop the existing real-world blockchain.
1 INTRODUCTION
B-Ride proposes a decentralized ride-sharing service on a public blockchain to address centralization, privacy, trust, and fee concerns in conventional platforms. It combines cloaked trip data, blockchain-based matching and contracts, and a deposit mechanism for accountable participation.
- Motivation: Centralized ride-sharing providers expose trip information to intermediaries, creating single-point-of-failure, data-disclosure, service-outage, and high-fee risks.The paper cites a service fee reaching up to 20% and examples of large-scale data leakage and outage.
- Blockchain foundation: Smart contracts provide self-executing and self-enforcing ride-sharing logic without trusted authorities.The paper presents smart contracts as autonomous programs running on the blockchain.
- Proposed system: B-Ride removes intermediaries by implementing ride-sharing business logic with smart contracts on a permissionless blockchain.The proposed system uses public blockchain infrastructure to support decentralized participation and transparent execution.
- Privacy-preserving matching: Riders publish cloaked pick-up and drop-off regions and times, after which interested drivers perform off-line matching against their routes.Spatial cloaking replaces exact locations with cells or regions to reduce exposure of trip data.
- Trust and commitment: The system uses a time-locked deposit protocol with zero-knowledge set membership to make riders and drivers commit to agreed rides.The protocol is designed to support claim-or-fine behavior while preserving relevant location privacy.
2 PRELIMINARIES
This section introduces blockchain, smart contracts, cryptographic notation, set-membership proofs, and their security guarantees as foundations for B-Ride.
- Blockchain and smart contracts: Blockchain is an immutable, distributed, append-only structure whose nodes maintain transaction records through consensus.Smart contracts are programs executed by blockchain nodes, updating replicated state without third-party intervention.
- Blockchain and smart contracts: Blockchain provides transparency, liveness, and eventual consensus, while addresses support participation in the network.Transactions are visible to participants, valid blocks continue to be added, and nodes agree on the global state.
- Cryptographic notation: B-Ride uses pairing groups, bilinear maps, collision-resistant hashing, and random elements from Zp as cryptographic primitives.The pairing generator outputs groups G1 and GT of prime order p with an efficiently computable admissible bilinear map.
- Zero-knowledge set-membership proof: A zero-knowledge set-membership proof shows that a committed secret belongs to a public set without revealing the secret or explicitly listing the set.In B-Ride, Y = g^δh^γ is a Pedersen commitment, and the proof can be made non-interactive using Fiat–Shamir.
- Zero-knowledge set-membership proof: The proof system provides soundness, completeness, and zero-knowledge, so true statements convince honest verifiers without exposing secret state.These properties respectively prevent false proofs, accept correctly computed true statements, and reveal no information beyond statement truth.
3 NETWORK/THREAT MODELS AND DESIGN GOALS
B-Ride models a permissionless blockchain ride-sharing network with drivers, riders, and a location prover, while addressing privacy, cheating, payment, and trust requirements.
- Network model: The network uses Ethereum smart contracts to handle ride-sharing transactions and peer-to-peer payments on a permissionless blockchain.Drivers and riders can interact through lightweight nodes without storing a complete blockchain copy.
- Network model: A location prover authenticates a driver’s reported pickup location by confirming that it lies within its coverage.Roadside units are an example of infrastructure that can perform this confirmation.
- Ride-sharing cases: B-Ride considers identical rides, where pickup and drop-off match, and inclusive rides, where the rider’s destination lies on the driver’s route.Spatial and temporal slacks capture tolerated additional distance and waiting time.
- Threat model: The threat model includes public transaction visibility, global eavesdroppers, false trip reports, multiple uncommitted matches, and fare-payment cheating.The blockchain is trusted for execution correctness and availability, but not for privacy.
- Design goals: The design goals are resilience without a central organizer, rider-trip privacy, fair trust-less payment, and driver reputation management.The system is intended to avoid complete reliance on any trusted party while tracking driver behavior through reputation.
4 OUR PROPOSED SCHEME: B-RIDE
B-Ride organizes decentralized ride sharing into six phases covering trip generation, matching, commitment, payment, and reputation.
- B-Ride phases: B-Ride consists of six phases: trip data generation, bidding and selection, time-locked deposits, fair payment, and reputation management.The source names six phases while listing the final payment and reputation stages together.
4.1 Trip Data Generation
B-Ride generates generalized trip data by cloaking locations and times into cells and intervals, then forms possible trips for matching while performing cloaking off-chain.
- Spatial and temporal cloaking: Spatial cloaking maps exact pickup and drop-off locations to cells in a partitioned ride-sharing area.Cells may follow districts, neighborhoods, or uniform map partitions, replacing exact coordinates with containing-cell coordinates.
- Driver trip generation: A driver’s generalized trip can include a departure time, intermediate locations, and corresponding arrival times.The trip is represented using selected route points and their timing information.
- Spatial and temporal cloaking: Drivers and riders hide exact trip locations and times by representing them as zones and time intervals.The generalized representation includes cloaked locations and departure or arrival timing information.
- Possible-trip construction: The driver creates a set of possible trips from selected points, with its size depending on the number of chosen points n.The source states that the number of possible trips is mathematically expressed as a function of n.
- Rider request generation: A rider generalizes a request by mapping pickup and drop-off locations into cells and departure time into cloaked time.The rider request is represented using the same privacy-preserving abstraction as the driver trip.
- Off-chain processing: Cloaking of driver and rider trips is performed off-chain, for example on their smartphones.The blockchain receives the generalized data rather than performing the cloaking operation itself.
4.2 Bidding and Selection
B-Ride matches rider requests with driver offers through a transparent blockchain-based bidding process while concealing sensitive trip details. Riders evaluate feasible offers using spatial, temporal, price, and reputation preferences.
- Bidding and selection: B-Ride handles bidding and selection through a smart contract that matches rider requests with driver offers on the blockchain.The process is summarized in Algorithm 1 and illustrated by a schematic diagram.
- Ride requests: Riders publish requests using fresh blockchain addresses and cloaked pickup, drop-off, and time attributes, with an offer-expiry period.Fresh key pairs help avoid de-anonymization, while expiry limits when drivers may respond.
- Driver offers: Drivers verify spatio-temporal route compatibility, then send encrypted exact trip details and a public bid price to the smart contract.The encrypted offer contains exact pickup and drop-off locations and times; the bid remains public to support price competition.
- Offer evaluation: Riders select offers by comparing spatial and temporal tolerances, bid price, and driver reputation.The rider may prioritize different trade-offs, such as lower price versus greater walking distance or waiting time.
- Illustrative matching: In the illustrative route example, drivers use generalized trip tables to determine whether a rider request lies on their route before submitting an encrypted offer.The rider then compares the selected driver’s offer with other received offers.
4.3 Time-locked Deposit Protocol
B-Ride uses time-locked deposits and zero-knowledge set membership proofs to enforce ride commitments without revealing the exact pickup location. Valid arrival proofs return funds to the driver, while defaults transfer the balance to the rider as a penalty.
- Protocol purpose: The time-locked deposit protocol requires both rider and driver to deposit funds as guarantees against abandoning their ride commitments.The protocol replaces reliance on a trusted party with smart-contract conditions executed on the blockchain.
- Rider initialization: The rider initializes the contract with a set of obfuscated locations containing the actual pickup location and publishes corresponding cryptographic values.The contract receives the location set, associated values, and rider deposit.
- Driver commitment and arrival: The driver confirms commitment by depositing funds and later submits a zero-knowledge proof of arrival through a location prover.The location prover authenticates the reported location before the driver constructs the proof.
- Proof construction: Fiat-Shamir converts the interactive zero-knowledge set membership protocol into a non-interactive proof suitable for blockchain verification.This avoids requiring miners to agree on randomly chosen interactive challenges.
- Blockchain verification: The contract verifies the driver identity, proof timing, and set-membership conditions before releasing the contract balance.The proof is accepted when the commitment represents an element of the rider’s location set and the timing condition is satisfied.
- Outcomes: If the driver defaults, the contract transfers the balance to the rider after the timeout as a monetary penalty.A valid proof instead allows the driver to claim the balance and supports a reputation update.
4.4 Fair Payment in Trust-less Environment
B-Ride addresses fare estimation without trusting self-reported trip data, which can enable driver overcharging. Its pay-as-you-drive design initializes a fare deposit and uses elapsed distance during the trip for payment processing.
- Fare-estimation challenge: B-Ride frames fare estimation as a trust problem because drivers may report inflated distances or durations using tamperable smartphones.Such misreporting is identified as overcharging.
- Pay-as-you-drive: The pay-as-you-drive method initializes a fare-payment smart contract with a rider deposit before the trip begins.The down payment from the time-locked deposit protocol also contributes to the trip fare.
- Distance-based payment: During the trip, the driver periodically submits elapsed distance to the fare-payment contract for fare calculation.The supplied implementation material identifies the payment contract and its deposit-handling logic.
- Contract enforcement: The time-locked contract checks deadlines, sender identity, deposits, pickup timing, and proof validity before transferring payment or returning funds.A valid arrival proof transfers the balance to the driver, while an expired contract without proof returns the balance to the rider.
- Settlement and reputation: A valid proof increases the driver’s reputation score, while timeout handling transfers the contract balance back to the rider.The implementation records the reputation update and contains explicit rider-refund logic.
4.5 Reputation Management
B-Ride’s decentralized reputation model rates drivers using their arrival and completed-trip history, helping riders distinguish reliable from dishonest behavior. New drivers are constrained by an additional deposit requirement because they lack historical reputation.
- Reputation score: Each driver receives a blockchain-recorded reputation score that riders consider when selecting offers.The score reflects driver behavior and is managed without a third party.
- Score construction: The score combines arrival commitments with completed trips, so collecting deposits without finishing rides lowers the driver’s standing.Arrival and completion are recorded separately, with completion requiring a completed trip.
- New-driver safeguard: New drivers may be selected before their reputation declines, so each newly registered driver must deposit funds to refund riders if poor performance damages the account.This deposit addresses the absence of an established reputation history.
- Score interpretation: A score of 1 indicates commitment to all past trips; scores at or below threshold T trigger refunds, while intermediate scores remain acceptable but less preferred.Riders may favor drivers with higher scores among those above the threshold.
5 PERFORMANCE EVALUATIONS
The evaluation compares B-Ride’s functionality with existing ride-sharing systems and measures its implementation costs on Ethereum. The reported results indicate feasible execution, low storage overhead, and affordable estimated user costs.
- 5.1 Functionality: B-Ride combines rider privacy, trust, payment fairness, and transparency, whereas reviewed alternatives omit at least some of these functions.The comparison identifies missing location privacy or payment fairness in blockchain-based platforms and attacks or reduced transparency in another decentralized scheme.
- 5.2 Implementation: The implementation separates off-chain privacy processing from on-chain smart-contract execution and transactions.ZKSM setup, cloaking, encryption, and request generalization run off-chain.
- 5.2.2 Implementation and Results: 400K gas publishes the rider’s bidding contract, 80K retrieves offers, 320K deploys the deposit contract, 340K deploys payment, and 42K calls ProofOfDistance.These are reported rider-side per-trip gas costs.
- 5.2.2 Implementation and Results: 89K gas sends encrypted driver offers, 25K sends the driver deposit, and 360K validates the underlying ZKSM proof.The driver-side measurements cover offer submission, deposit, and proof validation.
- 5.2.2 Implementation and Results: With 40 trips, estimated driver cost is about $2 at the lower gas price and reaches $7.6 as gas prices increase; seven offers require about 12 KBytes of storage.The authors describe the resulting cost as low and practically acceptable.
- 5.2.2 Implementation and Results: Off-chain operations take less than a second when measured on a Raspberry Pi 3 using BN128 pairing-friendly elliptic curves.The experiment uses the device to emulate driver and rider hardware.
6 SECURITY AND PRIVACY ANALYSIS
The security analysis evaluates B-Ride under explicit ledger, encryption, and ZKSM assumptions. It argues that the protocol preserves confidentiality and anonymity while constraining malicious-driver and malicious-rider behaviors through deposits, proofs, reputation, and public verification.
- Correctness and efficiency: Correctness and efficiency rely on an ideal public ledger, correct public-key encryption, and completeness of the underlying ZKSM.Precompiled contracts reduce on-chain proof-validation work to checking a few pairing equalities.
- Data confidentiality: Public rider records expose encrypted offers, a ZKSM proof, and elapsed distance, while semantic security and zero knowledge protect the underlying trip information.Elapsed distance is treated as nonrevealing because both rider and driver already know it.
- Rider anonymity: Rider anonymity is preserved against address linking, proof-based linking, and payment-phase linking through one-request addresses, ZKSM, changing set elements, and elapsed-distance-only disclosure.The analysis identifies these as the three considered anonymity threats.
- Malicious drivers: Driver misbehavior is constrained by deposits, ZKSM soundness, reputation tracking, and rider verification of the reported distance before payment.A driver can lose a deposit for failing to prove arrival, while distance checking addresses unfair payment.
- Malicious riders: Malicious rider behavior is addressed by requiring a ride deposit, enabling driver validation of ZKSM setup signatures, and allowing public verification of elapsed distance.These controls target fake reservations, forged setup data, and manipulated payment distance.
7 RELATED WORK
Prior ride-sharing research spans centralized privacy protocols, peer-to-peer systems, blockchain platforms, and distributed or vehicular infrastructures. The reviewed alternatives commonly retain trusted components or omit privacy, anonymity, transparency, or other target functionality.
- Blockchain platforms: Existing blockchain ride-sharing platforms such as DACSEE and Arcade City are described as lacking location privacy or anonymity.The review distinguishes these platforms from B-Ride’s privacy objectives.
- Centralized systems: Centralized systems address ride matching and privacy through service-provider filtering based on homomorphic secret sharing and secure equality testing.The cited SRide approach determines suitable drivers while protecting users from the provider and curious users.
- Peer-to-peer systems: A peer-to-peer ride-sharing scheme removes the service provider but exposes matching users’ real identities, enabling tracking and excessive information disclosure.The scheme is described as lacking rider privacy despite its decentralized management network.
- Other distributed architectures: Other distributed frameworks may depend on trusted infrastructure or resource-constrained roadside units, creating operational or storage concerns.The reviewed proposals include trusted service nodes and private blockchains maintained by RSUs.
8 CONCLUSION
B-Ride decentralizes ride sharing on a public blockchain while addressing privacy, accountability, security, trust, and fair payment. Experiments indicate practical on-chain and off-chain overheads and applicability in a trust-less environment.
- B-Ride decentralizes ride sharing atop a public blockchain and is practical in terms of on-chain and off-chain overheads.
- Its design addresses the tension between blockchain transparency and privacy, and between user accountability and anonymity.
- The time-locked deposit protocol protects against malicious behavior by dishonest drivers and riders.
- The reputation management system tracks driver behavior and discourages dishonesty by excluding poorly behaving drivers from future trips.
- Pay-as-you-drive enables riders to complete trips and drivers to receive fares in a trust-less environment.