# Blockchain-Enabled NextGen Service Architecture for Mobile Internet Offload
## 5 Deployment and Testing on Blockchain Network  
The smart contract of the proposed framework is deployed on Ethereum's _testnet_ to understand the behaviour of the smart contract in a real blockchain environment. The working conditions of the _testnet_ are similar to _mainnet_, except the factor that _Ether_ used in _testnet_ have no real monetary value. The smart contract is first tested using _hardhat_[30], which is an Ethereum development environment using various test cases. A _Metamask_ wallet [31] is created to store the _Ether_ used for transactions on the _testnet_ blockchain. Alchemy [32] is a web3 development platform used to deploy the smart contract on _testnet_. This platform provides node management for decentralized applications and helps in creating, testing and monitoring web3 applications. The smart contract is deployed on _Goerli testnet_ because it uses proof-of-authority (PoA) as a consensus algorithm, and the proposed framework suggests this consensus algorithm. The deployment process of a smart contract on the Ethereum testnet can be followed using Web3 University's deployment guide [33]. The execution of the smart contract on Ethereum's _testnet_ is analysed based on various parameters, such as computer units, median response time, transaction fee, gas price, and Mempool time. Table 2 shows the results obtained from _testnet_ for three use cases: deployment, successful offloading and rejected offloading. The use case of \"deployment\" corresponds to the first-time deployment of the smart contract on the blockchain. The use case of \"Successful Offloading\" indicates a case when the user, WiFi provider and MNO complete all procedures correctly and offloading is offered successfully. The use case of \"Rejected Offloading\" means that something wrong happens, such as a user providing the incorrect  
Figure 6: Delay and Jitter Sum Analysis for Offloading and No Offloading. number, the user providing the incorrect OTP, etc., and the smart contract is not executed, hence, offloading is rejected. The experiment was carried out multiple times to obtain the average results; for example, \"Successful Offloading\" use case requests are made 538 times, whereas for the \"Rejected Offloading\" use case, 311 requests are made. In the \"deployment\" use case, 1.9 of the computing unit is used, and the median response is received in 19 ms. For \"Successful Offloading\", i.e., successful smart code execution, 4.95 of the average computing unit is used, whereas the response is received in 21 ms.  
For the \"Rejected Offloading\" use case, an average computing unit of 4.34 is used, and the response is received in 20 ms. The transaction fee for the \"deployment\" use case to deploy the smart contract on blockchain is 0.0000001067369019 Ether, whereas a gas price of 43.370762893 is used. For the use cases \"Successful Offloading\" and \"Rejected Offloading\", the minimum transaction fees are 0.000396528108050536 and 0.000435436518074808 Ether, respectively, among all the requests made during the experiments. For the use cases \"Successful Offloading\" and \"Rejected Offloading\", the maximum transaction fees during all the experiments are 0.000604122568830418 and 0.000600562306691219 Ether, respectively. The minimum gas prices during the experiments are 14.970103747 and 16.448946739, whereas the maximum gas prices are 19.635407054 and 19.526036567 for the use cases \"Successful Offloading\" and \"Rejected Offloading\", respectively. The Mempool time in the case of deploying the smart contract is 00:00:08. For other use cases, the minimum Mempool times received are 00:00:07 and 00:00:03, whereas the maximum Mempool times are 00:00:30 and 00:00:35, for \"Successful Offloading\" and \"Rejected Offloading\", respectively. The average Mempool times for both use cases are calculated to be 00:00:17 and 00:00:20 respectively. The results obtained are promising, but, for smooth quality of service, the proposed framework suggests using private blockchain, which should significantly reduce the median response time.