In this assignment, you will design and implement a highway toll system, SpeeDrive, based on Ethereum. You will not receive any interfaces or grading scripts this time. This assignment is incredibly hands-off and allows a tremendous degree of freedom.

As with all assignments, don’t hesitate to Google, but do not copy verbatim or directly from your peers. Your code must compile and run to receive any credit.

There won’t be a template for HW7, simply reuse your HW6 template folder and remove all contracts.

Submission guidelines: Push frequently to your GitHub Classroom repository before due.

GitHub Classroom invite for HW7: https://classroom.github.com/a/03Xg8dJl

Deadline: Dec 7, 2022 23:59 PST

SpeeDrive (8%)

SpeeDrive is a highway toll system similar to FasTrak.

• Fees are charged based on on and off-ramp locations using its own ERC-20 token (SPD).
  • Fees don’t necessarily correspond to the distance between on and off-ramps, so don’t make that assumption.
    • We don’t know the distance between any given on and off-ramp pair anyways.
    • On and off-ramps are identified by their exit / junction names (string).
  • Upon entry, allowance is checked to ensure the driver has at least 10 SPD approved to be spent by the toll system.
    • Else, revert the function call, thus denying entry.
  • Fees are paid (deducted from allowance) upon exit.
• SPD Token specifications:
  • Name: SpeeDrive
  • Symbol: SPD
  • Decimals: 18
  • Total supply: ?
    • Supply starts off from zero.
    • Users can mint SPD tokens using Ether with a ratio of 1 Ether = 1 SPD.
  • You do not need to implement your own ERC-20 interface or implementation from scratch. Feel free to use OpenZeppelin’s template.
• The system should be able to be paused in case of malfunction.

1) Interface Planning (2%)

You must come up with your own SpeeDrive interface in Solidity and get approval from me before implementation. In the interface, every single function must be thoroughly documented in NatSpec format.

Functions in HW5 skeleton code are documented in NatSpec format, thus it can serve as a good reference.

Approval from me is needed before you can proceed to the next part.

2) Implementation (4%)

You will implement your SpeeDrive interface and custom ERC-20 token.

3) Functional Tests (2%)

You must write 2 sets of functional tests for SpeeDrive and SPD Token, so 4 functional tests in total. One test that walks through all functions normally, the other test where you try to perform actions that shouldn’t be allowed and check if the smart contract stops you. Every single require() you implement must be tested.