BlockHouse: Blockchain-based Distributed

Storehouse System
Doriane Perard∗ , Lucas Gicquel† and Jérôme Lacan∗
∗ ISAE-Supaero, Université de Toulouse, France
† Edokial, Causse Comtal, 12340 Bozouls
Email: ∗ [Link]@[Link]
† [Link]@[Link]
arXiv:2001.07016v1 [[Link]] 20 Jan 2020

Abstract—We propose in this paper BlockHouse, a ledger, but this could be problematic for companies storing
decentralized/P2P storage system fully based on pri- critical data.
vate blockchains. Each participant can rent his unused The recent developments of blockchains have shown that
storage in order to host data of other members. This
system uses a dual Smart Contract and Proof of Re- such systems can provide trust in a competitive system
trievability system to automatically check at a fixed without trusted third party. The idea of integrating this
frequency if the file is still hosted. In addition to trans- tool in a distributed storage system is quite natural.
parency, the blockchain allows a better integration with However, companies want to control the access to their
all payments associated to this type of system ( regular data and so, traditional public blockchains like Bitcoin
payments, sequestration to ensure good behaviors of
users, ...). Except the data transferred between the or Ethereum, where anonymity is omnipresent, can not
client and the server, all the actions go through a smart be used. These are the reasons why private blockchains
contract in the blockchain in order to log, pay and have been created: indeed, these blockchains manage the
secure the entire storage process. users’ account and check the user’s identity at each con-
nection. This kind of blockchain is also more efficient than
I. Introduction the public ones: they require only few seconds and few
computation power to create a block.
To face the huge increase of data generated by appli- Our proposal is a distributed storage system managed
cations, enterprises must manage their storage by taking on a private blockchain. A storage smart contract contains
into account the reliability, confidentiality and privacy. the amount of data and the storage duration. In addition
Local storage is the first possibility and is optimal for to transparency, this allows a better integration with all
confidentiality and privacy. However, despite the numerous payments associated to this type of system (regular pay-
existing local storage systems, it is not really easy to ments, sequestration to ensure good behaviors of the users,
ensure the full system reliability. As a consequence, small ...). The system also periodically checks that data is really
or medium enterprises often choose to focus on their main stored on the servers by using cryptographic tools, called
activity and externalize this kind of service. Proof of Retrievability (PoR) [1] that will be stored on the
In this case, the most evident solution is using cloud blockchain as well. Except the data transferred between
storage which is cheap and reliable. This main issue of this the client and the server, all the actions go through a smart
choice is probably the confidentiality and privacy. Indeed, contract in the blockchain in order to log, pay and secure
even if the data can be locally encrypted before being the entire storage process.
stored on the remote cloud, this solution is generally not The paper is organized as follows. We present the related
recommended for critical data. works in section II. All the details about BlockHouse are
A potential solution would be to collaborate with presented in section III. We propose some extensions in
trusted associate enterprises to share the storage resources section IV before concluding in section V.
in a kind of peer-to-peer network. In other words, com-
panies having unused storage capacity can rent this to II. Related works
other enterprises. Technically, this type of service can be In this Section, we first introduce the key concepts of
supported by an extensive literature on both reliability PoR which is one of the main components of our system.
and confidentiality. Then we will present other works using blockchains and
One of the potential issues in this distributed system is storage systems.
that all the system members must agree on the amount, 1) Proof of retrievability: is a mathematical tool that
duration and storage reliability of each file. One of the allows a server to prove to a client that it does have specific
system members could ensure the role of trust third party data, that can be fully recovered. The client sends random
by logging all the file exchanges and transactions in a challenges, and the server answers with a concurring proof.
A proof is much smaller than the original file, therefore it
can be frequently transferred. To verify it, the client needs
the metadata, a small amount of data computed from the
original file. It is thus possible to be sure that the file is still
stored on the remote server, without having to download
entirely.
These concepts were introduced by Juels and Kaliski
[2].The survey [1] is a good overview of existing proofs of
retrievability classified according to different attributes.
2) Distributed storage and blockchains: Since
blockchains are managed by a peer-to-peer network,
it is quite natural to integrate it in a distributed storage
system. Storj, BlockStore and Sia are 3 different systems
that propose P2P storage using blockchain. Fig. 1: Initialization step
Sia [3] is a Bitcoin-based blockchain aiming at storing
client files on several hosts. The contracts between the
clients and the hosts are stored on the blockchain. The
wanted, the price, the file sequestration needed). Every
file is first split into encrypted chunks and encoded with
participant in the blockchain network is able to know who
erasure codes [4]. The hosts are asked to provide regu-
wants what.
lar proofs-of-storage (with a limited number of possible
challenges). However, in such a public system, the end of Thanks to a reputation score, based on the blockchain
the contract just relies on the reputation and on the file history, every node can be rated on different criteria:
redundancy which incites the host to return the file to the on one hand, the clients are rated on their number of
client. litigation, on the other hand, hosts are rated on the ratio
The Storj system [5] uses similar concepts and suffers of succeed proofs to submitted proofs. When a potential
from the same drawback to not provide guarantees on host with enough free storage wants to host the data, it
the file recovery at the end of the contract. This is not makes a transaction Á to request an agreement with a
acceptable for companies. client he found sufficiently rated. When a client has chosen
BlockStore [6] is one of the first to detail the overall the best host, it makes a last transaction  to validate
scheme of the file storage process. It sets up all the the agreement. It can choose several hosts to improve
advanced storage system basics. It uses Space Wallet, a availability. It finally transfers the full payment of the file
special structure that tracks available storage space on all storage to the smart contract.
nodes. Their technical choice is to reduce the blockchain The client sends the data to the host(s) (Ã) and gen-
weight by storing only failing proofs in the blockchain. The erates the metadata for the future proofs of retrievability
other features (audits, transfer, ...) are off-chain. However, (Ä).
it does not solve the file recovery issue at the end of the This initialization phase ends when the host sends its
storage. first proof of retrievability Å.
III. BlockHouse description 2) Sequestration: To assure that both participants hon-
estly play the game, they must deposit some tokens in
This section presents our proposal BlockHouse, which a smart contract in Á and Â. These tokens are a kind
can be decomposed into three steps: The initialization of sequestration, to push them to respect the contract
which mainly includes the negotiation of the storage con- until the end. There are two types of sequestration, with
tract, then the storage and audit part which contains different goals. Both are deposited by the storage server
the periodic proofs-of-retrievability and the corresponding when he responds positively to a proposal.
payments, and the end of the contract which is the most
critical with the final payment and the client file restitu- • The first sequestration, called file sequestration, is
tion. sent to the client if the hosting server is not able to
return the original file.
A. Initialization step • The second sequestration is used in case of conflict at
Fig. 1 presents the initialization step of the BlockHouse the end of the contract. Indeed, if the client declares
protocol. that he can not download the file back, it is not
1) Contract creation: A node (the client) which wants possible to be sure that the client is honest or not.
to rent some storage can make a proposition to the net- In this case, we have to ask to other nodes to check,
work. To do this, he makes a special transaction (À in and they are rewarded with the dishonest node’s
the Fig.) with some details about his data (the data size, sequestration. These tokens will be called auditors
the contract duration, the proof of retrievability frequency sequestration, and both parties have to deposit it.
 • Early termination by the client: in the event that the
client decides to early terminate the contract, each
party recovers its sequestration, and the money used
to pay the proofs is fully sent to the server.
• Early termination by the hosting server: in the event
that the server decides to early terminate the con-
tract, the client recovers his sequestration and money
used to reward the proof, but also the file sequestra-
tion from the server. The server recovers its auditors
sequestration.
Fig. 2: Audits • Incorrect proof of storage: if there is too much in-
correct proofs of storage from the hosting server, the
contract is terminated. As the previous case, the client
recovers his sequestration and money used to reward
the proofs, but also the file sequestration from the
server. The server recovers its auditors sequestration.
• Ending download issue: this is the most complex
case. The customer must issue a correct termination
message at the end of the contract, when it has suc-
cessfully downloaded its file. In the event that it sends
an incorrect message, it is not possible for the rest of
the network to judge which one of the two parties
Fig. 3: End of the contract is dishonest. Indeed, the client may not succeed in
downloading the file because the server does not make
it available, or may try to cheat to receive the file
B. Storage and audit part sequestration from the server. To decide between the
Fig. 2 presents the second part of the BlockHouse two, we use others nodes, called auditors.
protocol, which is repeated according to the announced D. Auditors
frequency.
Once these formalities have been completed, the host Since the file is downloaded outside the blockchain, in
has to frequently perform proof of retrievability to be case of disagreement it is impossible for a network user
payed. The way we propose to implement the time in the to know who is right. To know if the client is lying (and
blockchain is discussed in IV-B. therefore the file is available) or if the server is lying (the
The challenge is randomly generated from the file is not available), other nodes, called auditors, are asked
blockchain itself, as explained in IV-A. Thus, it is to check. The chosen auditors who correctly answer (i.e.
deduced directly from the system and not required to be in agreement with the majority) are rewarded with a part
chosen by one node and sent to the others, saving storage of the auditors sequestration.
space and bandwidth. Since verification is time-consuming, it may be useful to
Every time the host performs a proof of retrievability, implement sanctions, for example banning a user who is
it includes it in a new transaction (Á). A smart contract at fault, in order to encourage everyone to act honestly.
receives this transaction, and check the proof using the This is possible because we are in the case of a private
initial data. If this proof is asked (the frequency is good) blockchain, where nodes are identified and accepted in the
and correct, a payment is sent from the smart contract to network.
the host (Á). Auditors must be selected randomly from the blockchain
and in sufficient quantity to ensure a majority of honest
C. End of the contract response, as we explain in IV-C.
Fig. 3 presents the last part of the BlockHouse protocol,
IV. Discussion
with a classic end (without issue).
In common use, just before the end, the client has to A. Random data (seed)
download its file À. In the meantime, the host continue to As explained previously, we want the blockchain to
create proofs of retrievability Á. If the downloaded file is randomly generate random challenges and choose auditors.
correct, the client announces it in a special transaction Â. In the blockchain, the too obvious way would be to use
Then, the sequestrations are given back to their owners the block hash as a seed for a pseudo-random number
(Ã) and the file is deleted (Ä). generator. However, a party can control the hash of a block
However, there are other reasons why the contract could to predict the future block hash [7] and then control the
be interrupted: future challenges.
 p = 4/5 p = 5/7 p = 2/3
In Fig. 4, we represent the probability to have a majority
Proba of dishonest majority
0
10 of dishonest auditors depending on the number auditor
10−1 nodes.
10−2
The probability is lower than 10−6 when there are at
10−3
10−4 least 41 nodes with p = 4/5, 101 nodes with p = 5/7 and
10−5 181 nodes with p = 2/3.
10−6 V. Conclusion
10−7
10−8 The increasing popularity of blockchains reveals all the
10−9 possibilities a decentralized ledger can offer. Nonetheless
50 100 150 200 250 300 blockchains can also have other usages.
Number of auditor nodes n In this paper, we introduce a new usage of blockchains in
Fig. 4: Probability to have a dishonest majority, depending a private context, with the aim of proposing a new decen-
on n, with p = 4/5, p = 5/7 and p = 2/3. tralized storage system. The BlockHouse system is based
on a protocol including three main steps done on-chain: the
storage contract initialization, regular audits and the end
Other ways to generate random numbers would be using of the contract. It is mainly based on cryptographic proofs
multiple blockchain elements like the i-th block hash in- of retrievability which allow smart contracts to verify that
stead of using the last block hash, smart contract address, hosts are storing the data correctly. This system allows to
timestamp, client or server address, last proof hash, etc. extend the trust on the data stored by the servers thanks
to the blockchain.
B. Regular trigger The major problem that could arise in our system would
To make sure that every host still hosts the clients’ be that the blockchain size increases significantly and
files, the system itself will incite them to create a proof then becomes complicated to store. In order to fix that
at a specific and fixed frequency. Working with a private problem, erasure codes can be used as a way to cancel
blockchain, it is not possible to use the block number as this growth [9].
fixed frequency: indeed, in this context, blocks are only
Acknowledgement
created when new transactions are processed. We can only
work with a clock. We thank Yann Bachy for his comments that greatly
As we can see in the block validation algorithm section improved the paper.
of [8], blocks are validated if each nodes’ clock in the net- References
work are synchronized with at most 15 minutes difference.
[1] C. B. Tan, M. H. A. Hijazi, Y. Lim, and A. Gani, “A survey
Thanks to this feature, it is possible to use the nodes’ clock on proof of retrievability for cloud data integrity and availabil-
in the smart contract to determine the date of every proof. ity: Cloud storage state-of-the-art, issues, solutions and future
trends,” Journal of Network and Computer Applications, vol. 110,
C. Probability to have a majority of honest auditors pp. 75–86, 2018.
[2] A. Juels and B. S. Kaliski Jr, “Pors: Proofs of retrievability
To evaluate the probability to have a honest majority, for large files,” in Proceedings of the 14th ACM conference on
let us denote n the number of nodes chosen to be auditors. Computer and communications security. Acm, 2007, pp. 584–
We note p the probability one node responds correctly, and 597.
[3] D. Vorick and L. Champine, “Sia: Simple decentralized storage,”
Xn the total number of correct answers. 2014. [Online]. Available: [Link]
We assume that the Xn can be modeled as realizations [4] J. Li and B. Li, “Erasure coding for cloud storage systems: A
of an independent discrete random variable following a survey,” Tsinghua Science and Technology, vol. 18, no. 3, pp. 259–
272, June 2013.
probability binomial distribution with probability p. [5] S. Wilkinson, T. Boshevski, J. Brandoff, and V. Buterin, “Storj
We need a minimum number of nodes in the network for a peer-to-peer cloud storage network,” 2014.
the blockchain to work properly, and for the consensus to [6] S. Ruj, M. S. Rahman, A. Basu, and S. Kiyomoto, “Blockstore: A
secure decentralized storage framework on blockchain,” in 2018
be valid. We therefore assume that this number is sufficient IEEE 32nd International Conference on Advanced Information
to be able to approximate the binomial distribution by a Networking and Applications (AINA). IEEE, 2018, pp. 1096–
normal distribution (n ≥ 30, np ≥ 5 and n(1 − p) ≥ 5): 1103.
[7] K. Chatterjee, A. K. Goharshady, and A. Pourdamghani, “Prob-
− 1 ( √ x−np )2
abilistic smart contracts: Secure randomness on the blockchain,”
1 x−µ 2
e− 2 ( σ ) e 2 np(1−p) arXiv preprint arXiv:1902.07986, 2019.
f (x) = √ =p √ (1) [8] E. Ruchevits, “Block protocole 2.0,” 2015. [Online].
σ 2π np(1 − p) 2π Available: [Link]
c02254611f218f43cbb07517ca8e5d00fd6d6d75/Block-Protocol-2.
The probability to have a dishonest majority is: [Link]
Z n − 12 ( √ x−np )2 [9] D. Perard, J. Lacan, Y. Bachy, and J. Detchart, “Erasure code-
 Z n2 based low storage blockchain node,” in IEEE International Con-
n 2 e np(1−p)

Pm = p 0 ≤ Xn ≤ = f (x)dx = p √ (2) ference on Blockchain. IEEE, 2018.
2 0 0 np(1 − p) 2π