Sia: Simple Decentralized Storage

1 Sia: Simple Decentralized StorageDavid VorickNebulous ChampineNebulous 29, 2014 AbstractThe authors introduce Sia, a platform for decentral-ized Storage . Sia enables the formation of Storage con-tracts between peers. Contracts are agreements be-tween a Storage provider and their client, definingwhat data will be stored and at what price. Theyrequire the Storage provider to prove, at regular in-tervals, that they are still storing their client s are stored in a blockchain, making thempublicly auditable. In this respect, Sia can be viewedas a Bitcoin derivative that includes support for suchcontracts. Sia will initially be implemented as an alt-coin, and later financially connected to Bitcoin via atwo-way IntroductionSia is a Decentralized cloud Storage platform that in-tends to compete with existing Storage solutions, atboth the P2P and enterprise level. Instead of rentingstorage from a centralized provider, peers on Sia rentstorage from each other.

2 Sia itself stores only the stor-age contracts formed between parties, defining theterms of their arrangement. A blockchain, similar toBitcoin [1, 12], is used for this forming a contract, a Storage provider (alsoknown as ahost) agrees to store a client s data, andto periodically submit proof of their continued stor-age until the contract expires. The host is compen-sated for every proof they submit, and penalized formissing a proof. Since these proofs are publicly veri-fiable (and are publicly available in the blockchain),network consensus can be used to automatically en-force Storage contracts. Importantly, this means thatclients do not need to personally verify Storage proofs;they can simply upload their file and let the networkdo the acknowledge that storing data on a single un-trusted host guarantees little in the way of availabil-ity, bandwidth, or general quality of service. Instead,we recommend storing data redundantly across mul-tiple hosts.

3 In particular, the use of erasure codescan enable high availability without excessive will initially be implemented as a blockchain-based altcoin. Future support for a two-way pegwith Bitcoin is planned, as discussed in EnablingBlockchain Innovations with Pegged Sidechains [5].The Sia protocol largely resembles Bitcoin except forthe changes noted General StructureSia s primary departure from Bitcoin lies in its trans-actions. Bitcoin uses a scripting system to enable arange of transaction types, such as pay-to-public-key-hash and pay-to-script-hash. Sia opts instead to useanM of Nmulti-signature scheme for all transac-tions, eschewing the scripting system entirely. Thisreduces complexity and attack also extends transactions to enable the creationand enforcement of Storage contracts. Three exten-sions are used to accomplish this: contracts, proofs,and contract updates. Contracts declare the inten-tion of a host to store a file with a certain size and1hash.

4 They define the regularity with which a hostmust submit Storage proofs. Once established, con-tracts can be modified later via contract specifics of these transaction types are definedin sections 4 and TransactionsA transaction contains the following fields:FieldDescriptionVersionProtocol version numberArbitrary DataUsed for metadata or otherwiseMiner FeeReward given to minerInputsIncoming fundsOutputsOutgoing funds (optional)File ContractSee: File Contracts (optional) Storage ProofSee: Proof of Storage (optional)SignaturesSignatures from each Inputs and OutputsAn output comprises a volume of coins. Each outputhas an associated identifier, which is derived from thetransaction that the output appeared in. The ID ofoutputiin transactiontis defined as:H(t|| output ||i)whereHis a cryptographic hashing function, and output is a string literal. The block reward andminer fees have special output IDs, given by:H(H(Block Header)|| blockreward )Every input must come from a prior output , so aninput is simply an output and outputs are also paired with a set ofspend conditions.

5 Inputs contain the spend conditionsthemselves, while outputs contain their Merkle roothash [2]. Spend ConditionsSpend conditions are properties that must be metbefore coins are unlocked and can be spent. Thespend conditions include a time lock and a set of pub-lic keys, and the number of signatures required. Anoutput cannot be spent until the time lock has ex-pired and enough of the specified keys have addedtheir spend conditions are hashed into a Merkletree, using the time lock, the number of signaturesrequired, and the public keys as leaves. The root hashof this tree is used as the address to which the coinsare sent. In order to spend the coins, the spend con-ditions corresponding to the address hash must beprovided. The use of a Merkle tree allows parties toselectively reveal information in the spend example, the time lock can be revealed withoutrevealing the number of public keys or the number ofsignatures should be noted that the time lock and numberof signatures have low entropy, making their hashesvulnerable to brute-forcing.

6 This could be resolvedby adding a random nonce to these fields, increasingtheir entropy at the cost of space SignaturesEach input in a transaction must be signed. The cryp-tographic signature itself is paired with an input ID,a time lock, and a set of flags indicating which partsof the transaction have been signed. The input ID in-dicates which input the signature is being applied time lock specifies when the signature becomesvalid. Any subset of fields in the transaction can besigned, with the exception of the signature itself (asthis would be impossible). There is also a flag to in-dicate that the whole transaction should be signed,except for the signatures. This allows for more nu-anced transaction actual data being signed, then, is a concate-nation of the time lock, input ID, flags, and everyflagged field. Every such signature in the transactionmust be valid for the transaction to be File ContractsA file contract is an agreement between a storageprovider and their client.

7 At the core of a file contract2is the file s Merkle root hash. To construct this hash,the file is split into segments of constant size andhashed into a Merkle tree. The root hash, along withthe total size of the file, can be used to verify contracts also specify a duration, challenge fre-quency, and payout parameters, including the rewardfor a valid proof, the reward for an invalid or missingproof, and the maximum number of proofs that canbe missed. The challenge frequency specifies how of-ten a Storage proof must be submitted, and createsdiscretechallenge windowsduring which a host mustsubmit Storage proofs (one proof per window). Sub-mitting a valid proof during the challenge windowtriggers an automatic payment to the valid proof address (presumably the host). If, at the end of thechallenge window, no valid proof has been submitted,coins are instead sent to the missed proof address(likely an unspendable address in order to disincen-tivize DoS attacks; see section ).

8 Contracts definea maximum number of proofs that can be missed;if this number is exceeded, the contract becomes the contract is still valid at the end of the con-tract duration, itsuccessfully terminatesand any re-maining coins are sent to the valid proof , if the contract funds are exhausted be-fore the duration elapses, or if the maximum numberof missed proofs is exceeded, the contractunsuccess-fully terminatesand any remaining coins are sent tothe missed proof or missing a proof results in a newtransaction output belonging to the recipient speci-fied in the contract. The output ID of a proof dependson the contract ID, defined as:H(transaction|| contract ||i)whereiis the index of the contract within the trans-action. The output ID of the proof can then be de-termined from:H(contract ID||outcome||Wi)WhereWiis the window index, the number ofwindows that have elapsed since the contract wasformed. The outcome is a string literal: either valid-proof and missedproof , corresponding to the va-lidity of the output ID of a contract termination is definedas:H(contract ID||outcome)Where outcome has the potential values success-fultermination and unsucessfultermination , corre-sponding to the termination status of the contracts are also created with a list of editconditions, analogous to the spend conditions of atransaction.

9 If the edit conditions are fulfilled, thecontract may be modified. Any of the values can bemodified, including the contract funds, file hash, andoutput addresses. As these modifications can affectthe validity of subsequent Storage proofs, contract ed-its must specify a future challenge window at whichthey will become , peers could create micro-edit chan-nels to facilitate frequent edits; see discussion ofmicropayment channels, section Proof of StorageStorage proof transactions are periodically submittedin order to fulfill file contracts. Each Storage prooftargets a specific file contract. A Storage proof doesnot need to have any inputs or outputs; only a con-tract ID and the proof data are AlgorithmHosts prove their Storage by providing a segment ofthe original file and a list of hashes from the file sMerkle tree. This information is sufficient to provethat the segment came from the original file. Becauseproofs are submitted to the blockchain, anyone canverify their validity or invalidity.

10 Each Storage proofuses a randomly selected segment. The random seedfor challenge windowWiis given by:H(contract ID||H(Bi 1))whereBi 1is the block immediately prior to the be-ginning the host is consistently able to demonstrate pos-session of a random segment, then they are very likelystoring the whole file. A host storing only 50% of thefile will be unable to complete approximately 50% ofthe Block Withholding AttacksThe random number generator is subject to manip-ulation via block withholding attacks, in which theattacker withholds blocks until they find one thatwill produce a favorable random number. However,the attacker has only one chance to manipulate therandom number for a particular challenge. Further-more, withholding a block to manipulate the randomnumber will cost the attacker the block an attacker is able to mine 50% of the blocks,then 50% of the challenges can be manipulated. Nev-ertheless, the remaining 50% are still random, so theattacker will still fail some Storage proofs.