Cloud storage reduces the need for local storage and enables ecient le sharing. The conventional cloud storage is a centralised system that relies on a trusted party to provide all services. In such a centralised architecture, rst, data on cloud storage is readable, modiable, and deletable by the cloud provider. For example, on 31 Jan 2017, six hours of database data of the famous git repository manager gitlab.com was deleted by just a simple delete command 6 . Second, the availability of the data on cloud storage is questionable [5] while saving copies to multiple cloud providers to increase data availability needs a considerable eort due to vendor lock-in [1].
In this paper, we propose EthDrive solve those problems. EthDrive is a distributed storage client which allows users to upload, download, and share les. It utilizes content-addressable distributed le system as the underlying storage and blockchain as the distributed database. All les are stored in the distributed storage while the le records are registered on the blockchain. Files are indexed by a unique le ID which is associated with the content address, storage system used, last uploader, last update time, authorised editors, authorised administrators (people who can add and remove editors), immutability (whether the le can be updated or deleted), and comments. That information is stored in the blockchain via a smart contract, which is a program deployed and running across the blockchain network [7]. Blockchain is an emerging technology that allows participants in an industry ecosystem to transact with each other without relying on a central trusted authority to record and validate transactions [8].
Information in EthDrive is secured because only authorised personnel can mutate particular information. Information like the editor and time of the last update is assigned by smart contract. Any invalid attempt will be denied by the blockchain network. Read access control is enabled by encrypting the content address and/or the le content itself. From the nature of both blockchain and content-addressable distributed le system, high availability is easily achievable while data integrity is guaranteed. In addition, it provides data provenance driven by the distributed consensus which is dicult to achieve for conventional cloud storage without a trust [2]. EthDrive resolves users' most concerns when using cloud storage [4] -security, control, vendor lock-in, congurability, and speed to activate new services and expand capacity.
There are related work which aim to address those problems. Such as, Permacoin [6], Sia 7 , and Storj 8 . However, they require currency in the respective blockchain valuable while EthDrive can leverage multiple blockchains with different mechanisms and benet from pre-existing cryptocurrency ecosystem.
Conventional Cloud Storage In the scenario of sharing les using conventional cloud storage, cloud provider stores the data uploaded by the le publisher. In this model, it is not transparent to the users about how the cloud provider would deal with those les. File integrity and availability don't often come with their services [3]. Even le integrity is included in their Service Level Agreement(SLA), le consumers are unable to verify it unless putting extra eorts. For provenance, we can only trust the cloud provider which can be unfavourable [2].
Peer-to-Peer Data Storage and File Sharing Peer-to-peer technology has been used for distributed data storage and le sharing. Such a system allows users to access data that is stored in other computers connected to the same peer-to-peer network. A centralised server is not required. Existing products include BitTorrent9 , IPFS (InterPlanetary File System)10 and etc. All these Peer-to-peer techniques use dierent mechanisms to share data with peers and to replicate data across nodes. IPFS is an open source content-addressable, globally (peer-to-peer) distributed le system for sharing a large volume of data with high throughput. IPFS has several limitations, including 1) originality of les cannot be veried, and 2) limited mutability.
Blockchain The blockchain data structure is a time-stamped list of blocks.
Blocks are containers that aggregate transactions. The blockchain provides an immutable data storage where existing transactions cannot be updated or deleted. Cryptography and digital signatures are used to prove identity and authenticity. For a basic description and technical details of blockchain, please refer to [8]. Smart contracts are programs running on blockchain. All interactions with smart contracts are recorded immutably, and veried and accepted by the whole blockchain. Ethereum11 is the most widely-used blockchain that supports general-purpose (Turing-complete) smart contracts at the time of this research being conducted.
By using blockchain as a reliable distributed database with content-addressable peer-to-peer storage, EthDrive guarantees that the les to be downloaded from storage providers are intact. EthDrive is currently based on Ethereum and IPFS. However, it does not couple with these specic implementations. EthDrive is known to facilitate scenarios with no trusted third party or the le content must be identical to the one uploaded by the indicated le uploader. Fig. 1 gives an overview of EthDrive with all the available commands. File publisher and le consumer need to congure the environment via ethdrive init and start daemon process of EthDrive via ethdrive start before other operations. Users can upload and download les via ethdrive upload and ethdrive download. A user can use ethdrive upload to upload a le, then announce the le ID to allow others to locate the le. A user can also share a le without uploading it when he/she knows the IPFS address of the le via ethdrive upload with --not_provide as argument.
Every le is retrieved via ethdrive download based on a customised le ID, which is assigned by the le publisher who uploads the rst version of the le. File ID is logical and understandable. Conceptually, a le ID is associated with information including the information publisher, a purpose, and the data related to that purpose. Using dierent naming space is achieved by using other smart contracts with the same interface.
Read access control is implemented by uploading an encrypted le content address and/or an encrypted le content using symmetrical encryptions. Only personnel having the correct key can download and/or decrypt the le content. Write access control is enforced by the smart contract, which implements a permission control based on the blockchain account addresses. When a user calls the smart contract to modify the le record for a particular le ID, the smart contract checks whether the user has the permission based on the blockchain account public key and the corresponding signature.
Users could add and get comments via ethdrive comment to/from a le record if the le publisher enabled this feature. Every comment has three information associated, including the le ID it comments on, the comment author and the comment content. Since all comments are stored in the blockchain, the provenance of the comments is assured in the same way as le records. The comment mechanism enables exible interactions between the le author and the comment author. For example, a group of people uses EthDrive to publish an article. Comments are accepted. There are reviewers being invited to review this article. While everyone can post their comments on to the le record, the authors will only concern about the reviewers' reviews (in the form of a comment). By checking the comment authors, those reviews can be identied, authenticated, and conrmed to be intact without a centralised party.
Any node in the network can become a provider of a certain le via ethdrive provide. Also, people who download the data becomes a temporary provider. The Distributed Hash Table (DHT) of IPFS is able to connect them when a correct data content address is given.
Data Integrity Data integrity is achieved because 1) the content address of a le will change when the le is modied and 2) the content address is stored on the blockchain and can only be updated by authorised users.
Data Availability Both blockchain and content-addressable distributed le system are based on the peer-to-peer network. Users of EthDrive are in the Ethereum blockchain network and IPFS DHT network at the same time. There are two types of le provider in the IPFS network, including permanent providers and temporary providers. Permanent providers are nodes that provide the les. They might be the le publishers or storage provider who have some contracts with the le publishers to help them serve the les. Temporary providers are the ones that have downloaded the le. They will provide the le until the cache is cleaned. There are nodes providing other les which share some common blocks with the le. Such nodes are also providers of parts of the le.
Traceability The editor and the time of every update are recorded in the smart contract and accepted by the whole blockchain network. Thus, the transactions recorded on the blockchain provide the provenance of the le record. Using the provenance, le consumers are able to conrm that the content is the one that originally comes from the intended le publisher.
Customisability EthDrive is not coupled with the current implemented smart contract. It can work with the smart contract that implements the dened interfaces. This feature allows dierent logics to be used making EthDrive highly customisable to t dierent situations while modication of the client program is not needed.
Limitations of blockchain and IPFS apply to EthDrive. For example, Ethereum blockchain needs to be synchronised before using EthDrive. The database is growing without a bound -synchronisation can be time-consuming and the database might occupy a large space. This can be solved by deploying the light client protocol version of Ethereum which is under development at the time the research is being conducted. The download speed of IPFS can be slow down sometimes because the DHT routing of IPFS is still immature at the time the research is being conducted. However, the famous 51% attack12 on the blockchain will only aect the data availability property of EthDrive while other main properties are intact.
This section gives a detailed example to show how EthDrive can improve the quality of data storing in the context of Internet of Things. Fig. 2 b) gives a conceptual architecture of IoT using EthDrive. Nodes of the peer-to-peer network are made up of IoT gateways, storage providers, and data consumers. EthDrive provides the provenance of the data and guaranteed data integrity to increase the condence for the data from the data consumers' perspective. The following shows the steps of how EthDrive is used.
Registration on the network Storage provider registers itself to the network by uploading (ethdrive upload) an empty le named IOT_IDS. The le is used to store the ID of all the IoT gateways which the storage provider decides to provide the les they generate and upload using EthDrive. The le ID represents the storage provider ID on the network. IoT gateway registers itself to the network by uploading an empty le named DATA_IDS. The le is used to store the le ID of all the les the IoT gateway generates and uploads using EthDrive. The le ID represents the IoT gateway ID on the network.
Registration of a IoT gateway to a storage provider IoT gateway registers itself to a storage provider by adding a comment (ethdrive comment) on the le record whose le ID is the storage provider ID. The storage provider periodically checks if there is any new comment. If there is, the storage provider then decides whether accepts the request. If it accepts, the IoT gateway ID will be added to the le IOT_IDS. The modied le IOT_IDS is then uploaded (ethdrive upload) to replace the old le.
Data uploading IoT gateway packs data collected from the sensors into a le and uploads (ethdrive upload) it using EthDrive with a le ID. The le ID is added to the le DATA_IDS, then DATA_IDS is uploaded to replace the old le. The storage provider periodically checks for all the IoT gateway IDs registered to see whether they have uploaded any new le. If they do, the storage provider will call ethdrive provide to become a provider of the newly uploaded les.
Access data EthDrive uses a le ID to locate the data content address in Blockchain. If it is encrypted, data consumer will supply the correct key to EthDrive to get (ethdrive get) the data content address. Then, it downloads the data to the data consumer's local storage. If the data integrity is corrupted, the data will not be available since the IPFS component of EthDrive won't be able to locate it by the data content address stored in the blockchain. The time of upload and the data publisher can be veried by retrieving the le record information via ethdrive query.
Uploading les via ethdrive upload only creates a transaction for storing the le content address on to the Ethereum blockchain and uploads the le content to the local IPFS node. Thus, there is no network latency for ethdrive upload.
We conducted an experiment to evaluate the performance of downloading les using ethdrive download. In this experiment, we compared the download performance between EthDrive and a conventional cloud storage, AWS S313 in US standard region. We deployed four EthDrive nodes in four locations: Hong Kong, Tokyo (Japan), Sydney (Australia) and Pittsburgh (USA). The locations are selected so that they are geographically distinct to simulate a global peerto-peer network. The test les are generated by a random data generator. We queried IPFS network and conrmed that there is no block in the test les shared with any pre-existing le on the network. All the test les are provided by three providers. An Ethereum private blockchain is used. which is expected because the retrieval of le content address is done on the local blockchain data. Most of the time EthDrive spent is for downloading the les from the IPFS network. The yellow column (Ethereum Lookup Time) in Fig. 3 is too small to be viewable. In this experiment, EthDrive is faster than AWS S3 when the le size ≤ 20MB and is slower when the le size > 30MB. This shows that IPFS is not handling large les eciently at the time of this experiment being conducted. This result suggests that when the le size is small, additional features provided by EthDrive doesn't come with a performance penalty.
By utilizing blockchain and content-addressable distributed storage, the demonstrated EthDrive can have all the basic requirements for a reliable cloud storage fullled. It includes le integrity, reliable permission control, and high availability. In addition, EthDrive provides custom le ID as a means to locate the les to facilitate easy access, sharing and management, and comment mechanism to increase its versatility. For our future work, the following features/functions can be implemented on top of the current version: 1) An extension which allows users to pay to particular parties to have them provide certain les to ensure the minimum availability of those les. The payment will be done automatically when they are providing the le and terminated when they do not. 2) After integrating with other content-addressable distributed le systems, les can be downloaded from all the networks concurrently to boost the performance. 3) Mount les ltered by some conditions to the le system via Filesystem in Userspace (FUSE) to facilitate convenient use. We also plan to evaluate EthDrive more systematically through using additional evaluation criteria.