Storage contracts are one of the most significant safety features on the Sia network. The contracts make it possible to interact safely with otherwise unknown hosts. Unlike traditional contracts, these contracts are cryptographically enforced by a blockchain, which means there is no legal paperwork, no jurisdiction conflicts, and no lawsuits. It's a much cleaner and more efficient way of doing business.
The most important part of Sia's storage contracts is the host collateral. When a contract is formed, the renter puts money into the contract to pay the host. The host also puts money into the contract, money which will be forfeit if the host loses the data. The host cannot leave the contract early - if they agree to store the data for 12 weeks they must hold the data for the full 12 weeks or face penalties. This financial incentive makes it easy for renters to do business with unknown hosts.
These contracts are also host friendly. The renter must put the money into the contract up-front. If the host stores the data for the agreed upon time, the host is guaranteed to get paid, even if the renter changes her mind about payment.
Sia leverages one of the core strengths of blockchains - making it easy for people who don't know each other to trust one another.
Contracts are a separate kind of transaction on the blockchain. Here is an example of a contract being created on the blockchain: Sia explorer.
Siacoin Inputs Parent ID 1d80012fa8b608e363b90afb6fc51a8fdec7dbc4aacb0c8d19712ca5ccab4ea6 Address 9bf8a3832f5393ee75c207f4e11917d3a3dcb7e048217f3cf769e4fbc8547acb1d1a534a72a0 Value 65 siacoins Parent ID 1dc246cd80ff0f80aa3836944e8330e5ee94079045465a7e21ff59b163c65dc1 Address 57350439442e3fe06b1c5fc6b369941d25eef200b7fc930ab273b9253302bdd461940e8fe6b0 Value 31 siacoins File Contracts ID 95e96414bd0685e1caa915f47d55f0170d2b950c07996515ac0e9a2e10237257 File Size 0 bytes File Merkle Root 0000000000000000000000000000000000000000000000000000000000000000 Payout 85 siacoins Revision Number 0
This transaction has two coin inputs and, instead of a regular coin output, it outputs a file contract. The first input is the host putting up collateral money as a guarantee that data will not be lost, and the second input is the renter allocating money to spend on uploads, downloads, and storage. When the host fails to deliver a promise, her collateral will be voided and the host will suffer financial loss.
The host and the renter worked together to create a transaction, and signed it together. The finances in this contract can now be dynamically allocated to the host as the renter uploads, downloads, and stores content.
All unspent renter's money will be returned to him when the contract ends. On the other hand, if the money is entirely spent, the renter cannot upload / download / store anything until he forms a new contract.
The next interesting thing about this contract is that, like most contracts on Sia, it starts at 0 bytes and with an empty Merkle Root. And there is also a Revision Number that is set to 0. Data is uploaded to the contract 4MB at a time. Each time that data is uploaded, the Merkle root changes, the revision number is increased, and the money stored in the contract is moved from the renter to the host. So, for the duration of the contract, money is moved around inside the contract, and not on the blockchain. When the contract ends, the totals are committed to the blockchain, and that's when the renter pays and the host gets her revenue and collateral back. More on that in the Revisions section.
File contract revisions in Sia work much like payment channels in Bitcoin. All communication between a renter and a host is billed in a revision, which is essentially like a transaction that doesn't get logged in the blockchain. It allows for many transactions to be performed securely and instantly between two parties (in this case, the renter and the host) without ever needing to show the intermediate transactions to the blockchain. The only transactions that need to be shown to the blockchain are the setup transaction (which is the initial file contract) and the final revision (typically broadcast a few hours before the host performs the storage proof).
Each file contract revision has a revision number. If there is already a revision on the blockchain, a newly broadcast revision will only be accepted if the new revision has a higher revision number. If it is accepted, the new revision will entirely replace the old revision.
Using this method, once a renter and a host have set up a contract with eachother, they can make instantly secure transactions hundreds of times per second. A single file contract can store a virtually unlimited amount of data (trillions of terabytes), meaning the real limit of the contract is almost always defined by how much storage the host actually has.
A few hours before the contract expires, the host will post the final revision to the file contract. Typically up to this point the on-blockchain contract will say '0 bytes'. (If the host ever goes offline, the renter will post the most recent revision, ensuring that the host is properly penalized for losing data). Once the revision has been posted, every data transaction performed between the renter and the host will be accounted for in a single small blockchain transaction.
The contract will then expire, and the host will have a small window of time (typically 24 hours, but often shorter) to prove that they still have the data. This is the storage proof. If the proof appears on the chain within this time, the host is paid. If the proof does not appear within this window, the host is penalized.
The proof itself is performed using the file size and the Merkle root. The file as seen by the blockchain consists of a bunch of tiny 64 byte data segments. The blockchain will pick one at random (using the hash of the block prior to the contract expiration) and require the host to show the blockchain the data in that segment, alongside a Merkle tree proof that the data is in the Merkle root of the file. This is a probabilistic proof, requiring the host only to reveal a tiny bit of data. The host has no control over which piece of data she is required to reveal.
If the host tries to cheat, there is a chance that the blockchain will select a piece of data that the host doesn't have, and the host will fail to provide the storage proof. Because the host will lose collateral as well as revenue, this is a bad deal for the host. Storing half the data means there is a 50% chance that the host will receive no revenue at all and forfeit all collateral. It is much cheaper (in the long run) for the host to store all of the data than to try to cheat. The expected financial benefit to cheating is always negative, as long as the host has put up collateral.