Project Objectives – by building this project you will:
- Design a multi-feature dApp back end with several structs and mappings.
- Return arrays of structs from view functions for search screens.
- Connect the contract to HTML/JavaScript pages with Web3.js.
Synopsis
EcoRide is a decentralised application (dApp) that encourages carpooling as a sustainable and cost-effective alternative to driving alone. Sharing rides reduces traffic, fuel use and carbon emissions, and a blockchain back end gives drivers and passengers a shared, transparent record of rides and bookings without a central company controlling the data.
Drivers publish rides (from, to, date, time, fare, seats and vehicle type). Passengers search by location, date or vehicle and book seats. The contract tracks seat availability, booking status and payment status, while the HTML/JavaScript front end (in the GitHub repository) provides the user interface through Web3.js.
Implemented Features vs Future Scope
Implemented in the contract
- User registration (address, name, phone, e-mail)
- Login lookup and user details
- Publish, cancel and re-activate rides
- Search rides by location, date and vehicle type
- Book seats with automatic seat counting and fare calculation
- Booking lists for drivers and passengers
- Booking-status and payment-status updates
Ideas for future versions
- Automated Ether payments and escrow
- Route matching and navigation integration
- Ratings, reviews and reputation
- Carbon-saving dashboard and rewards (badges)
- Real-time notifications using events
- Identity verification with privacy protection
Contract Architecture
| Part | Details |
|---|---|
| DataBank.sol | Structs RegiterUsers (user account), PublishRide (13 fields incl. seats nop, booked seats nopstatus, status flags), RideBooking (booking with passenger, seats, amount, booking/payment status) and PublishRideBookingList (ride + booking combined for listings) |
| CarpoolingContract.sol | Contract CarPoolingContract; imports contracts/DataBank.sol |
| mappings & keys | registerUsersList, publishRideList, bookingList (index → record), with counters rideKey and bookingKey acting as primary keys starting at 1 |
| write functions | RegisterUserAccount, AddRide, cancelRide, activateRide, MapRideBooking(rideno, passenger, nop, charges), rideBookingStatusUpdate, ridepaymentupdates |
| view functions | loginPanel, getUserDetails, searchView, getMyRides, getPassengerRides, searchByLocation, searchByDate, searchByVehicle, getPassengerBookedRides, getDriverBookedRides, seat/status helpers |
Search functions use a two-pass pattern: the first loop counts matching rides (comparing strings with keccak256(abi.encodePacked(...)) and skipping the searcher’s own rides), a memory array of exactly that length is created with new PublishRide[](count), and a second loop fills it. The function returns (PublishRide[] memory, uint count) – a common pattern for listing data in a front end.
How It Works
1. RegisterDriver and passenger accounts
2. PublishDriver adds a ride (seats, fare)
3. SearchPassenger filters by location / date / vehicle
4. BookSeats reserved if available; fare = seats × charge
5. UpdateBooking confirmed and payment status marked
When booked seats equal the ride’s seats, isRideBookingDone becomes true and the ride is full.
Key Requirements (Concepts Used)
- Structs and mappings used like database tables with primary and foreign keys (Chapters 12, 13).
- Memory arrays of structs returned from view functions (Chapters 4, 10).
- String comparison for searches (Chapter 9).
- Loops and decision making (Chapters 7, 8).
- Web3.js front end (Project 6).
How to Run
- Create
contracts/DataBank.solandcontracts/CarpoolingContract.solin Remix and deploy CarPoolingContract to your local chain. - Download the HTML and JS files from the GitHub repository and update the contract address and ABI in the scripts.
- Follow the nine video parts to register users, publish rides, search, book and update statuses.
Limitations and Extension Exercises
| Observation in the teaching version | Improvement to try |
|---|---|
| Functions accept addresses as parameters and have no access control, so any account can act for another (e.g. cancel any ride). | Use msg.sender as the acting user and check ownership with modifiers. |
| Payment status is only a flag; no Ether moves. | Make booking payable, hold the fare in escrow and release it to the driver after the ride. |
| Phone numbers and e-mails are stored publicly on-chain. | Keep personal data off-chain; store only what the contract needs. |
| Searches loop over all rides, which becomes slow as data grows. | Use events plus an off-chain indexer for search, keeping the contract for state changes. |
| No events are emitted. | Emit RidePublished, RideBooked and PaymentMarked events for the front end (Chapter 20). |
Key Takeaways
- Structs + mappings + counters can model tables such as users, rides and bookings.
- View functions can return arrays of structs to power search screens.
- Production dApps add access control, escrow payments, events and off-chain storage of personal data.
Videos : Project 7 : EcoRide – A Carpooling dApp
Carpooling dApp Part 1
Carpooling dApp Part 2
Carpooling dApp Part 3
Carpooling dApp Part 4
Carpooling dApp Part 5
Carpooling dApp Part 6
Carpooling dApp Part 7
Carpooling dApp Part 8
Carpooling dApp Part 9
Resource Files
Question / Answer (15 questions)
Answer : To promote carpooling as a sustainable, cost-effective way to commute by letting drivers publish rides and passengers find and book seats, with ride and booking records kept on a blockchain.
Answer : RegiterUsers (user accounts), PublishRide (published rides), RideBooking (bookings) and PublishRideBookingList (a combined ride-and-booking record for listings).
Answer : With counters rideKey and bookingKey that start at 1 and increase after each new ride or booking; the records are stored in mappings at index key − 1.
Answer : nop is the number of passenger seats offered in a ride; nopstatus is the number of seats already booked.
Answer : It computes the free seats (nop − nopstatus). If they are at least the requested seats, it updates nopstatus, marks the ride full when no seats remain, calculates the amount (seats × charges) and stores a new RideBooking.
Answer : They loop over stored rides, copy matching rides into a memory array of PublishRide structs and return the array together with the number of matches.
Answer : Search by location (from/to), by date and by vehicle type, plus listings of a driver’s rides, a passenger’s rides and booked rides for both.
Answer : No. ridepaymentupdates only sets paymentstatus to true. Automating payments would require payable booking functions and an escrow mechanism.
Answer : The HTML/JavaScript front end uses Web3.js to call the contract’s functions – sending transactions for registration, rides and bookings, and calling view functions for searches.
Answer : Any account can pass someone else’s address and act on their behalf. Using msg.sender as the acting user and checking ownership prevents this.
Answer : Blockchain data is public and permanent, so personal contact details would be exposed to everyone and could never be removed.
Answer : Each search loops over all rides; with many rides the loop needs more computation and can hit gas limits even for view calls. Off-chain indexing of events is the usual solution.
Answer : Events such as RidePublished and RideBooked let the front end and indexing services update screens and notify users in real time without repeatedly scanning contract storage.
Answer : Automated payments, route matching and navigation, ratings and reviews, a carbon-impact dashboard with rewards, real-time notifications and privacy-preserving identity verification.
Answer : Function return values of reference types must be in memory; the search builds a temporary array of matching structs in memory and returns it to the caller.
MCQ Test : Check Your Understanding (5 questions)
Select an option and press Check Answer, or answer all questions and press Submit Test to see your score. Each answer comes with an explanation.
Bibliography/References
The notes, questions and MCQs on this page are original explanations written for this course. The works listed below were consulted and are cited for attribution and further reading. Product names, logos and trademarks belong to their respective owners. Short quotations, where used, are marked and attributed.
- Solidity Team. (n.d.). Types (value types, reference types, mappings, operators, conversions). Solidity Documentation. https://docs.soliditylang.org/en/latest/types.html
- Solidity Team. (n.d.). Contracts (creating contracts, visibility and getters, function modifiers, constant and immutable, functions, events, custom errors, inheritance, abstract contracts, interfaces, libraries). Solidity Documentation. https://docs.soliditylang.org/en/latest/contracts.html
- ChainSafe Systems. (n.d.). Web3.js Documentation. https://docs.web3js.org/
- ethereum.org. (n.d.). Introduction to dapps. Ethereum Developer Documentation. https://ethereum.org/en/developers/docs/dapps/
- ethereum.org. (n.d.). Smart contract anatomy (events and logs). Ethereum Developer Documentation. https://ethereum.org/en/developers/docs/smart-contracts/anatomy/
- ethereum.org. (n.d.). Smart contract security. Ethereum Developer Documentation. https://ethereum.org/en/developers/docs/smart-contracts/security/