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.

2 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. Sia itself stores only the stor-age contracts formed between parties, defining theterms of their arrangement.

3 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.

4 Instead,we recommend storing data redundantly across mul-tiple hosts. 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.

5 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.

6 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.

7 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.

8 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.

9 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.

10 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).