1 Introduction

Blockchain, a term which has seemingly associated with almost all major domains that exist today in the world, is just a decade old promising technology. The technology which started as a backend technology to the technically sound Bitcoin cryptocurrency, today has ventured into supply chain, healthcare industry, education domain, logistics, corporate houses, inventory management, Internet of things etc. to mention a few. The key features which come inbuilt to blockchain majorly include the following and form the reason that all domains contend to associate with:

  • Security

  • Decentralization

  • Immutability

  • Transparency

  • Consensus

These features have evolved further over the decade and concepts such as smart contracts on blockchain have been introduced.

1.1 Smart cities

With the expansion and penetration of IoT [1] across, the concept of smart cities [2] is slowly evolving to realization. Worldwide huge investments are in place across countries and cities for implementation of the same. Various architectures have come up for the smart cities on how these ground realizations will lead to better lives, safety and comfort of the respective citizens. Smart cities employ a multitude of actuators, IoT sensors enabled by a large number of peripheral and IT devices to unite elements in the smart city ecosystem. These all connected devices in the smart city ecosystem are architectured to exchange large amounts of raw data amongst each other from which useful and vital information will be deduced mostly in real time to benefit the lives of citizens around.

1.2 Smart contracts

While in the year 2009 on 3rd January, while Satoshi Nakamoto gave this world the first 50 bitcoins, as a prelude to the vision of coordinating transactions amongst faceless nodes, he might not have envisaged the future. While as on date there are more than 2000 cryptocurrencies, mostly variants of the Bitcoin architecture, the world has moved further into the era of smart contracts [3].

Smart contracts are composed as computer codes deployed on the blockchain and are basically equivalent of traditional contract agreements coordinated vide special language software’s like solidity [4], that carries out the terms of the agreement recorded on a digital ledger. Figure 1 shows two clients 1 and 2 recording their transaction vide a smart contract which is linked to a blockchain. This transaction once indexed in the block becomes immutable and bores the characteristic advantage of a blockchain.

Fig. 1
figure 1

Smart contract schematic

Full size image

1.3 Interplanetary file system (IPFS)

IPFS [5] is a file sharing method amongst a peer-to-peer (P2P) network that essentially alters the conventional mode of sharing documents and files across the network. This is achieved by unambiguously identifying each file in a global namespace based on content addressing while linking all devices on the P2P network. Each node in IPFS is configured to store an accumulation of hashed files. Thus the deficiencies observed in the traditionally followed client server model are negated in IPFS. The main components in IPFS file sharing protocol [6] include the following:

  • Version Control system

  • Merkle Directed Acyclic Graph(DAG)

  • Self-certifying File System

  • Block exchanges

1.4 Blockchain and IPFS

The indexing of transactions in bitcoin blockchain is designed to get committed in a final state inside block in around 10 min [7]. This committing of the transaction inside the block is further based on the configured difficulty level as gets generated as per average time of creation of blocks at every 2016th block [8] in cycle. The minimum 10 min the blockchain takes would not be apt in a real time environment implementation wherein every transaction should be working in a real time mode.

It is also understood that there are many other factors that affect these 10 min time. While the focus of the paper remains on connecting blockchain and IPFS, it is also at the same time realized that these transactions in bitcoin blockchain are just hashes with very miniscule bits size. While in an envisaged scenario of smart cities, data will be kind of continuously populated from various sources and be of huge sizes too. This will be a gigantic task to be handled by a blockchain unless it is preconfigured and designed to handle real time transaction speeds aptly backed up by adequate IT resources [9].

To resolve the issue of large size data sets on blockchain, IPFS comes as a viable solution [10]. Vide Fig. 2, it is seen that each block has an additional attribute in form of IPFS hash which connects the hashes of various data sets deployed on IPFS. A typical expected smart city architecture with multiple data sets input point is seen in Fig. 3, which has storage and deployment of data sets on a blockchain enabled by IPFS. The major advantages accrued vide IPFS association with blockchain [11] will include the following:

Fig. 2
figure 2

IPFS hash in blocks

Full size image
Fig. 3
figure 3

Smart city schematic enabled by Blockchain on IPFS

Full size image

Ease of distribution: Since IPFS is a file distributing storage protocol, the access and secure availability comes easy for user nodes.

Single-Instance Storage: This refers to the negation of holding islands of data copies at various locations. IPFS, by virtue of its unique characteristics addresses data by hashes thus rendering integrity and distributed persistence of data.

File listing and exploring: Provisions quicker browsing of data.

Low Bandwidth requirement: Users can share data between each other with IPFS addressing thus abbreviating bandwidth requirements and expediting data sharing speeds.

Archiving: IPFS distributed storage offers immutable and integrated data storage with offline data access.

Merkle DAG ascertains unequivocally identified, immutable and permanently stacked data.

1.5 Related works

In this section, recent research work in the domain of smart cities has been discussed with benefits and limitations proposed.

In [12] the authors propose to use the IOTA platform, a distributed ledger built for the “Internet of Everything” along with IPFS for storage. While the focus of the paper has been on to create and store data generated in an “Internet of Vehicle” ecosystem for transportation, not much demonstration is seen on the IPFS front. In [13], proof-of-authority based consensus mechanism has been used to execute smart contracts in a distributed vehicular network in smart cities while saving on ethereum gas. In [14], the authors have proposed an architecture for smart vehicles enabled by blockchain and have centered to authenticate and build trust in the ecosystem wherein dynamic traffic rate has been considered for simulation and analysis. The performance is seen high when lots of traffic is simulated. Traditional method of storage is considered for storage of transactions in the blockchain architecture and access policy updates and user attribute revocation have not been considered. In [15], the authors have focused on kubernetes [16] for monitoring and managing IoT applications in a smart city environment. The storage part has been though mentioned by exploiting the IPFS technology but it has not been considered in detail in the demonstration simulations. In a similar work in [17], the authors focus on the association of IoT and big data in an envisaged smart city environment enabled by blockchain. The focus of the authors further to building up on literature review is to resolve issues of operations cost, poor security in architecture, privacy leakage enabled on delegated proof-of-stake consensus. The authors have proposed a P2P architecture to overcome blockchain data storage but not vide the IPFS protocol.

Another paper on blockchain association with smart cities [18], the authors have exploited the concept of ERC20 standards i.e. ethereum tokens, for monitoring water quality standards using IOT sensors enabled on blockchain. The storage part is mentioned to be based on [19] that analyses transmission and storage of cryptographically encrypted data vide low power wide area network over a permissioned blockchain.

1.6 Setup, Simulation and Results

For the setup part the following hardware and software’s have been used:

1.6.1 Hardware

  • Intel 9th Generation i7 CPU,NVIDIA GTX 1650 GPU with 512 GB PCIe SSD and 16 GB DDR4-2666 MHz RAM

  • Machine ID: 19c89160e20d4af7ab92ffe8aacca5fd

  • Boot ID: 9b93bb0d17414abc8acba258244c9c6b

1.6.2 Software’s

  • Ganache CLI v6.9.1 (ganache-core: 2.10.2)

  • MetaMask Ethereum Browser Extension in Mozilla Firefox Browser 73.0.1(64 bit) for Ubuntu

  • Oracle Virtualization box Version 6.0.18 r136238 (Qt5.9.5)

  • Operating System: Ubuntu 18.04.3 LTS

  • Kernel: Linux 5.3.0–40-generic Architecture: × 86–64

  • Truffle Suite v5.1.15 (core: 5.1.15)

  • Solidity v0.5.16 (solc-js)

  • Node v8.10.0 JavaScript runtime built on Chrome's V8 JavaScript engine

  • Web3.js v1.2.1

  • Node package manager, Npm 3.5.2

  • Remix Integrated Development Environment

The Ganache-CLI [20] generated set of Private- Public keys are produced as seen in Table 1, as used for experiment along with assumed simulated node role. Three smart contract files for demonstration have been created for specific function deployment on the blockchain integrated with IPFS. The metamask firefox [21] browser extension has been configured and connected with all these nodes as per the names available in Table 2 on local host port 8545. The truffle suite also has been configured to speak to the blockchain on same port. The tree structure of the truffle suite is seen in Fig. 3.

Table 1 Public private key sets generated on Ganache-CLI for setup
Full size table
Table 2 Smart city nodes details for setup
Full size table

The above pair of keys have been simulated as identification to various nodes deployed in Smart city ecosystem, the details of which is given in Table 2.

1.7 Simulation Sequence and conduct

  • Remix has been configured to listen at port 8545.

  • Ganache-CLI has been configured to quickly run an Ethereum blockchain simulated at port 8545 with 6 accounts on which further tests, execution of commands will be coordinated.

  • The six accounts so generated are added on the Remix ethereum on localhost:8545 network.

  • With the help of Truffle suite, the smart contracts are deployed on the governance smart city node Set-1.

  • Intranode transactions are simulated for generation of blocks.

  • The IPFS.sol smart contract is compiled on Remix ethereum and the same is published on IPFS distributed storage.

  • Finally the web link address generated with IPFS is seen where the sample IPFS.sol smart contract is seen.

2 Simulations and experiments

In an envisaged scenario of a Smart city ecosystem based on an Ethereum blockchain with data nodes as above in Table 1, an accident takes place on a highway. The following sequence of action takes place:

  • Detection of the accident by the sensors placed on the highway.

  • The detection leads to prompt activation of smart contracts [22] and deployment on the blockchain. For the simulation purpose, four smart contracts have been considered with brief details as below:

    • InfoNearDoc.sol: The smart contract immediately identifies the nearest doctor on the smart city ecosystem with the aid of geo location and sensor inputs. This intimation is made to the doctor while the smart contract is also inbuilt to provide crypto tokens as a felicitation measure of admiration based on his promptitude and hastened movement to the site.

    • InfoNearHosp.sol: The smart contract identifies the nearest hospital and informs for coordinating ambulance to the accident site.

    • MakeAmbWay.sol: This smart contract will activate the agencies at smart highway for activating green signal at traffic lights to coordinate undeterred movement to accident site for the ambulance.

    • IPFS.sol: This smart contract deploys on the blockchain for storing data vide IPFS.

  • Each of the above tasks on a ethereum blockchain will generate new contract addresses and will have effect into expansion of Gas, as configured( Gas limit as 6,721,975 and Gas price as 30,000,000,000 in subject simulations).

  • Besides, the above incident coordination, the smart city nodes (1–6 in the given simulation) will themselves be coordinating various exchanges of the ether tokens based on policies implemented and coordination of tasks.

The details of the simulations are seen in Fig. 4. The Ethereum blockchain in the simulation setup demands ethereum gas to continue itself executing on the blockchain in a running state constantly. Thus all such transactions including deployments and execution on the Ethereum blockchain network tariff in amounts of gas. This tariff depends primarily on the speed of execution of the contract which can be slow, normal or fast, as set. The gas expense at each of the deployments and transactions is seen in Figs. 4, 5 and 6 with the following parameters of transaction mining fees.

Fig. 4
figure 4

Transaction Mining Fees

Full size image
Fig. 5
figure 5

a File structure, b contracts compilation, c contract address

Full size image
Fig. 6
figure 6

Contract compilation and transaction hash for InfoNearHosp.sol

Full size image

Contract compilation and transaction hash for InfoNearHosp.sol is seen below in Fig. 6 along with the details of the contract address generated by Truffle Suite.

In the simulation and experiments intr smart city nodes in the smart city ecosystem, the following readings and transactions were observed along with 254 block details as seen in Table 3.

Table 3 Experiment data with block and intra smart city node transaction details
Full size table

Whilst the simulations which started with default values of 50 Ethers allotted to each of the participating C1–C6 cars, the final transaction states of Ether balance was observed as seen in Table 4.

Table 4 Intra smart city node transactions
Full size table

2.1 Deployment of IPFS.sol on blockchain

The IPFS.sol smart contract meant to store data files on IPFS distributed storage got deployed at the address 0 × 692a70D2e424a56D2C6C27aA97D1a86395877b3A as seen in the Fig. 7.

Fig. 7
figure 7

IPFS.sol Deployment at SET-1 node

Full size image

And the Metadata at IPFS [23] is published as per the following details.

browser/IPFS.sol: dweb:/ipfs/QmP1LcXJY1ZpqF75B4tPdyxGzfdWtYjicrHU8epGAmkysX.

metadata.json: dweb:/ipfs/QmZjrTRikUToSkSuBUMHYgcaxvPpYCV1T1tZPHSq8dJHBz.

The test publishing of the smart contract at IPFS distributed storage can be seen on live web at https://gateway.ipfs.io/ipfs/QmP1LcXJY1ZpqF75B4tPdyxGzfdWtYjicrHU8epGAmkysX

3 Conclusion and evaluation of results

While simulation serves and aids to align a proof of concept, but the difference is huge between its outputs and ground expectations- realizations. In this paper, the results obtained show a low scale architected IPFS enabled ethereum blockchain. IPFS has a definite future association in envisaged blockchain applications associated with upcoming smart cities, Internet of Things, Internet of Vehicles, Logistics, Citizen data kind domains etc. These domains have huge data sets to handle which in the traditional ways of storing data in blockchain will not suffice for. Thus IPFS comes as a viable solution for association. While through the proposed architecture, it seems workable to associate the applications and get the deemed outputs, there will be lots of challenges before such realizations take place. Few of the major challenges identified are briefly discussed below:

Scalability: Data sets to be handled will be of huge sizes vide 3 Vs of Big data(Velocity, Veracity and Volume).To handle such real time data sets, much more rugged and capable blockchain architectures need to be in place.

IPFS data reliability in distributed storage systems: Erasure codes such as Reed-Solomon (RS) codes or Zigzag based HDFS implementation do offer to improve data reliability, but they are still little far from implementation aspects.

Lack of blockchain platforms: Blockchain platforms peculiar and custom made to handle big data sets and associate with IPFS are still awaited. Promising platforms to look forward to include Ethereum, IBM Blockchain [24], Hyperledger Fabric [25],R3 CORDA [26], BigchainDB [27], IOTA [28] etc. Approaches like BlockIPFS [29] admit to achieve better trustiness of the data and authorship protection though.

Unique Identification in smart city ecosystem: All the participating nodes in the smart city ecosystem will be identified by unique set of Public–Private keys and thus security by individual holders will be of vital importance. A simple compromise by a cyber criminal or a careless holder can play havoc in a real time smart city ecosystem. A need to evolve and negate out such scenarios is deemed before going live and realizing a working smart city ecosystem.

Interoperability issues: Communication between participating devices and nodes with multiple software interfaces will need to be on the same platform and protocol to listen and transfer data to each other. Currently there is an absentia of such standards and protocols at global level. Thus there is a need to establish standards and protocols at an expedited pace.

Smart contracts languages: As on date few programming languages that support smart contracts include Solidity, Golang, Javascript, C +  + , Java and SQL etc. are available. The concern is with the expedited pace at which each of these is evolving to reach a stable version, which is currently not happening.

The paper has envisaged a scenario in the smart city ecosystem enabled by blockchain on IPFS and simulated the working flow of data sets. The work affirms that persistent consolidation of blockchains enabled on IPFS in the smart city ecosystems will cause substantial shifts across various industries affecting into introducing new business models and better lives for the human beings ahead.