Please enable JavaScript.
Coggle requires JavaScript to display documents.
Whitepaper
https://sia.tech/sia.pdf - Coggle Diagram
- A decentralized cloud storage platform that intends to compete with existing storage solutions, at both the P2P and enterprise level
- Instead of renting storage from centralized providers, peers on Sia rent storage from each other
- Sia itself stores only the storage contracts formed between parties, defining the terms of their arrangement. A blockchain similar to BTC is used for this purpose
- By forming a contract, the storage provider agrees to store the client's data, and to periodically submit proof of their continued storage until the contract expires
- Host is compensated for every proof submitted and penalized for missing proofs
- Since these proofs are publicly verifiable in the blockchain, network consensus can be used automatically to enforce these storage contracts
- Erasure codes are used to ensure the data is stored across multiple hosts to ensure availability, performance & general quality of service
- Initially, an altcoin. Expected to be 2-way pegged with BTC in the future
4.File Contracts
- An agreement b/w a storage provider and their client
- At the core of a file contract is the file's Merkle root hash
- To construct this hash, the file is split into segments of constant size and hashed into a Merkle tree
- The root hash along with the the total size of the file can be used to verify storage proofs
- Can also specify a duration, challenge frequency, & payout parameters, including the reward for a proof, and the max no. of proofs that can be missed
Challenge Frequency
- How often the storage proof must be submitted
- Creates discrete windows during which a host must submit storage proofs
- Submitted a valid proof triggers an automatic payment to the valid proof address (presumably the host)
- At the end of the challenge window, if no proof has been submitted, coins are sent to an unspendable address (burned?) to disincentivize DOS attacks
- Contracts define the max no. of proofs that can be missed, if this no. is exceeded, the contract becomes invalid
- If the contract is still valid at the end of the contract duration, it successfully terminates and any remaining coins are sent to the valid proof address
- Conversely, if the contract funds are exhausted before the duration elapses, or if the max no. of missed proofs is exceeded, the contract unsuccessfully terminates and any remaining coins are sent to an unspendable address (burned?)
Edit conditions
- File contracts are also crated with a list of "edit conditions" analogous to the spend conditions of a transaction
- If the edit conditions are fulfilled, the contract may be modified
- Any of the values can be modified, including the contract funds, file hash, and output addresses
- As these modifications can affect the validity of subsequent storage proofs, contract edits must specify a future challenge window at which they will become effective
Output
- Output ID = Hash of the output string literal "output"
- Block rewards & miner fees have special output IDs : H(H(Block Header) || "blockreward")
- Outputs contain the Merkle root hash of the spend conditions given in the input
Input
- Every input must come from a prior output, so an input is simply an output ID
- Inputs & Outputs are paired with a set of spend conditions
- These are properties that must be met before coins are unlocked and can be spent
- Include a time lock, set of public keys & the no. of signatures required
- An output cannot be spent until the time lock has expired and enough of the specified keys have added their signatures
- The spend conditions are hashed into a Merkle tree, using the time lock, the no. of signatures required, and the public key as leaves
- The root hash of this tree is used as the address to which the coins are sent. (This is like how TCP/IP sends packets across multiple hops. The receiver sends the packet to the source at the end of the transaction)
- In order to spend the coins, the spend conditions corresponding to the address hash must be provided
- The use of Merkle tree allows parties to selectively reveal information in the spend conditions. E.g. Time lock can be revealed without revealing the no. of public keys or the no. of sigs required
- NOTE: Time lock & no. of signatures have low entropy, making their hashes vulnerable to brute-forcing. This could be resolved by adding a random nonce to these fields, increasing the entropy at the cost of space efficiency
Resources - https://medium.com/coinmonks/implementing-merkle-tree-and-patricia-trie-b8badd6d9591
- Each input in a transaction must be signed. The Cryptographic signature itself is paired with an Input ID, a time lock, and a set of flags indicating which parts of the transaction have been signed
- Input ID: indicates which input the signature is being applied to
- Time Lock: indicates when signature becomes valid
- Any subset of fields in the transaction can be signed, with the exception of the signature itself
- There's also a flag to indicate that the whole transaction should be signed, except for signatures
- The actual data being signed = Concat(Time lock + input ID + flags + every flagged field)
- Every signature in the transaction must be valid for the transaction to be accepted
-
A Transaction contains the following fields:
- Version - Protocol version no.
- Arbitrary Data - metadata or otherwise
- Miner Fee - Reward given to the miner
- Inputs - Incoming funds
- Outputs - Outgoing funds (optional)
- File Contract
- Storage Proof
- Signatures
What is it?
- Storage proof transactions are periodically submitted in order to fulfil file contracts
- Each storage proof targets a specific file contract
- A storage proof does not need to have any inputs or outputs; only a contract ID & the proof of data are required
- Hosts prove their storage by providing a segment of the original file and a list of hashes from the file's merkle tree
- This info is sufficient to prove that the segment came from the original file
- Because the proofs are submitted in the blockchain, anyone can verify their validity or invalidity
- Each storage proof uses a randomly selected segment
- The random seed for the challenge window (Wi), is given by:
H(contractID | H(Bi-1))
where Bi-1 is the block immediately prior to the beginning of Wi
- If the host is consistently able to demonstrate possession of a random segment, then they are very likely storing the file
- A host storing only 50% of the file will be unable to complete approximately 50% of the proofs
- Block Withholding Attacks
- The random number generator to randomly select a segment is subject to manipulation via block withholding attacks, in which the attacker withholds the blocks until they find one that will produce a favorable random number
Problem - However, the attacker has only one chance to manipulate the random number for a particular challenge. Furthermore, withholding blocks will cost the attacker the block rewards
- If an attacker is able to mine 50% of the blocks, then 50% of the challenges can be manipulated. The remaining 50% will still fail storage proofs
How to protect agains such attacks? clients can specify a high challenge frequency and large penalties for missing proofs. This will deter any financially motivated attacker that controls less than 50% of the network
- For byzantine attacks, clients are advised to plan separately
- Hosts can only complete a storage proof if their proof transaction makes it into the blockchain
- Threat 1: Miners could maliciously exclude storage proofs from blocks, depriving themselves of transaction fees but forcing a penalty on hosts
- Threat 2: Miners could extort hosts by requiring large fees to include storage proofs, knowing that they are more important than the average transaction
- This is termed a "closed window" attack, because the malicious miner has artificially "closed the window"
Defense: To use a large window size. Hosts can reasonably assume that some percentage of miners will include their proofs in return for a transaction fee
- Because hosts consent to all file contracts, they are free to reject any contract that they feel leaves them vulnerable to closed window attacks
- Arbitrary Transaction Data
- Each transaction has an arbitrary data field which can be used for any type of information
- Nodes will be required to store the arbitrary data if it is signed by any signature in the transaction
- Nodes will accept up to 64 KB of arbitrary data per block
What is it used for?
- Provides hosts & clients with a decentralized way to organize themselves
- Can be used to advertise available space or files seeking a host, or to create a decentralized file tracker
-
Host Protections
- A contract requires consent from both the storage provider and their client, allowing the provider to reject unfavorable terms or unwanted files (e.g. illegal)
- The provider may also refuse to sign a contract until the entire file has been uploaded
- More flexibility to storage providers as they can advertise themselves as minimally reliable, offering a low price and a agreeing to minimal penalties for losing files and vice versa
- Responsibility of hosts to prevent themselves from DDOS attacks
Client Protections
- Clients can use erasure codes, such as regenerating codes, to safeguard against hosts going offline
- The codes operate by splitting the file into n pieces, such that the file can be recovered from any subset of m unique pieces
- Each piece is encrypted and stored across many hosts (HA)
- E.g. If only 10 out of 100 pieces are needed to recover the file, then the client is relying on the 10 most reliable hosts, rather than the average reliability
- Availability can be further improved by rehosting file pieces whose hosts have gone offline
- Performance - Clients can reduce the latency by downloading from the 10 closest hosts, or from 10 fastest hosts
- These downloads can be run in parallel to maximise b/w
Uptime Incentives
Caveats
- The storage proofs contain no mechanism to enforce constant uptime
- No provisions that require hosts to transfer files to clients upon request
- One might expect hosts to hold files and demand exorbitant fees to download them
How is it prevented?
- This attack is mitigated through the use of erasure codes as described above
- Gives the clients the freedom to ignore uncooperative hosts and work only with those that are cooperative
- As a result, power shifts from the host to the client and the download fee becomes an "upload incentive"
– Micropayments can also be enabled
Basic Reputation System
- clients need a reliable method for picking quality hosts
- Analyzing their history is insufficient, because it can be spoofed
E.g. A host can repeatedly form contacts with itself, agreeing to store large "fake" files, such as file containing only zeros
- To mitigate this Sybil attack, clients can require the hosts to also include a large volume of time locked coins
- If 10 coins are time locked 14 days into the future, then the host is said to have created a lock valued at 140 coin-days
- So clients can favor hosts that have high lock value to mitigate Sybil attacks
- Also, each client can have their own equation for picking hosts, and can use a large no. of factors, including price, lock value, volume of storage etc.
- Sia is a product of Nebulous Incorporate (a For Profit Company)
- Sia is intended to be a primary source of income for the company
- Currently, premining is not a stable source of income as it requires creating a new currency & tethering the company's revenue to the currency's increasing value
- When the company needs to spend money, it must trade away portions of its source of income
- Also pre-mining means one entity has control over a large volume of currency, and therefore potentially large and disruptive control over the market
Solution?
- Nebulous intends to generate revenue from Sia, in a manner proportional to the value added by Sia, as determined by the value of the network (or the contracts set up by the hosts and clients)
- This is achieved by imposing a fee on all contracts
- When a contract is created, 3.9% of the contract fund is removed and distributed to the holders of the siafunds.
- Nebulous Inc. will initially hold approx 88% of the siafunds, and the early crowd-fund backers of Sia will hold the rest
How can siafunds be used?
- Siafunds can be sent to other addresses, in the same way siacoins can be sent to other addresses
- They cannot, however, be used to fund contracts or reward miner fees
- When siafunds are transferred to a new address, an additional unspent output is created, containing all of the siacoins that have been earned by the siafunds since their previous transfer. These siacoins are sent to the same address as siafunds
- Siacoin is inflationary - The supply of Siacoins will increase permanently, and all fresh supply will be given as block subsidy to miners
- The first block will have 300,000 coins minted. This number will decrease by 1 coin per block, until a minimum of 30,000 coins per block is reached
- Following a target of 10 mins between blocks, the annual growth in supply is
- 90% (1), 39%(2), 21%(3), 11.5%(4), 4.4%(5), 3.2%(8), 2.3%(20)
Volatility
- The primary goal of Sia is to provide a blockchain that enforces storage contracts
- The mining reward, however, is just indirectly linked to the total value of the contracts created
- Therefore, initially, siacoin is likely to have high volatility. Hosts can be adversely affected if the value of the currency shift mid-contract
So what to expect?
- Expect hosts to increase the price of long-term contracts as a hedge against volatility
- Additionally, hosts can also advertise their prices in USD and convert to siacoin immediately after finalizing a contract
- Eventually, the use of two-way pegs with other crypto assets will give hosts additional means to insulate themselves from volatility
Why do we need SC and not USD?
- We need SC because we don't have to rely on another service to maintain the operation - 1 universal payment system
- USD is not available everywhere, but with SC it can be exchanged anywhere
- Removes operational complexity that comes with USD - record keeping, taxation, & private information sharing
- Bottomline - It enables a trustless, immutable blockchain that USD or any other fiat currency may not be able to achieve.
- Besides if you made the blockchain act like xdai where it was based on USD, based on current congress gossip, you would probably get shut down for being an unregulated stablecoin. So it's best that any stablecoin based blockchain system is outside govt controls for those risks
Summary
So it's basically - 1) To avoid the operational complexities that come with transacting in USD, 2) Having a universal payment system 3) Ensuring a trustless, immutable value exchange that USD may not be able to introduce since it's value is determined by central forces 4) Regulatory hurdles with stable coin based BC