# Analysis of Decentralized Storage Networks

### Overview
In this research we try to answer the not so outragous question (more in this [document](https://hackmd.io/@codex-storage/BkXOYFWjel)):
> Why can't we just use/repurpose existing decentralized storage solutions?

In this write-up I try to extract as much information as possible on the existing decentralized storage networks so that we have some idea of what they are, what their weaknesses are and what gaps can Codex fill?

In other words, we want to look at the problems these DSNs have so that we can actually work on solving them. I'm sure as we dig into this we will find many problems and it would be impossible to solve all of these problems of course but maybe we can solve few in a very good way which would give Codex/logos-storage a competitve advantage. I would say that I'm not looking at the usability aspect of it (although important) but rather looking at the protocols.

We start with the [research](https://drive.google.com/drive/folders/19rvWWoT219Dyp1f4BJFqeJY3xMK-Lx7l?usp=sharing) that was already done by Leo and Shachi, then look further if needed. That research looked at these DSNs: Filecoin, Storj, Sia, Arweave, and Ethereum Swarm. However, in here we will look at Arweave, Storj, and Sia.

## Arweave
We start with Arweave since it seems to be somewhat popular (you can export this document to Arweave apparently!).

My sources of information in doing this are:
- The Arweave [yellow paper](https://www.arweave.org/yellow-paper.pdf), unfortunately this is very outdated and most of the things here changed so not very reliable source.
- The [Arweave lightpaper](https://www.arweave.org/files/arweave-lightpaper.pdf), more recent and provide somewhat more information.
- The [Arweave Standards](https://github.com/ArweaveTeam/arweave-standards/tree/master), contain only few standards and are described somewhat poorly.
- This recent post on [data redundacy on arweave](https://permaweb-journal.arweave.net/article/data-redundacy-on-arweave.html), which seems to be published in their permaweb.

### Target Use-Cases
Let's start with the question of what are they focusing on? what are they selling really? durability? private storage? sensorship-resistance storage? what use-cases are they targeting?

Arweave calls itself "Ledger (database) of knowledge" so my assumption here is that they would target data or use-cases that require permanent storage for long period of time, use-cases with short-lived data/files would not make sense because well the most obvious reason is that to store you need to pay for 200 years of storage!

The main usecases are then: permanent public archives, immutable static webpages, basically anything that you need to store "forever" and doesn't change much, you can append but that is outside of the core protocol.

What it is not suited for is: small dynamic data, short-lived fils (e.g. in the Waku large file sharing use-cases), strong durability guarantees (measurable durability), high access data (access to data is not guaranteed and you'll most likely have to pay for access).

**Problem:** the protocol is not suitable for short-lived data/files because of the upfront payment for "200 years", this makes it difficult for use-cases such as sending large file attachments, personal backup? Although they claim they support decentralized apps, how?

**Problem:** For use-cases that require dynamic data (small continously changing data), the protocol is very difficult to adjust to these cases.

### Incentives
By looking at the Arweave papers, you see that the main mechanism for controlling the storage nodes behaviour is through incentives, and there are many in their design.

**Storage Endowment**
The first incentive is the upfront payment that a user pays to store the data and it is called endowment because the full amount is not transferred directly to the storage provider, but rather partial payments are distributed to many providers (those that mine blocks in the arweave blockchain). The upfront payment is for 20 replicas and 200 years they say! although this very difficult/impossible to confirm.

The durability guarantees in Arweave is completely reliant on the tokenomics. Remove the blockchain part (as in an alteruistic mode) and what you have is just nodes storing data and generating **weak** basic merkle proofs and there is no erasure coding to amplify the power of such proofs. The one nice thing that they still have is the packing technique which would ensure unique replicas so maybe you can use it to count how many unique replicas and check the health of a dataset. Although such packing is very cpu heavy and lack of incentives would make it difficult to enforce (see discussion on packing below).

**Reputation**
They seem to have a kind of tit-for-tat reputation system that is gossiped around between nodes based on how responsive nodes are. They say it is based on the Bittorrent one.

Arweave's off-chain social incentive is called the AIIA/Wildfire agent. Nodes score peers by responsiveness so unhelpful peers get deprioritized or dropped. Serving blocks/transactions keeps your score high and low-score miners risk slow propagation of their blocks (and losing rewards). That’s kind of an explicit precondition for practical mining. A miner who never serves will lose social rank -> slower block propagation -> lower probability their blocks get accepted -> fewer rewards. So this is not a hard guarantee, just an incentives game and there is no obligation to share the reputation list and no consensus for this.

**Services & Payment Channels**
One red flag that I felt in reading their design is the problem of data retrieval. How do they make sure that users can retrieve the data from nodes? What incentives are there to provide the data and not just use it for mining?
The incentives for retrieval seems to rely mainly on the reputation mechanism, which to me doesn't really make sense if the query is coming from a user rather than a storage node. The other thing they rely on so that users are kind of guaranteed they can retreive is the full replication to all nodes, so one of them must be honest.

Then they also mention the following which suggests centralization, and in practice, I would assume all traffic goes through this gateway not storage-providers/miners:
> Data Retrieval Process: Users typically retrieve data through Arweave gateways, which cache data and serve it over standard web protocols (HTTP). Direct retrieval from nodes is also possible using Arweave libraries/tools. Gateways act somewhat like buffer nodes or CDNs for the network.

and then they also offer this solution:
> They can also buy/sell disks with stored data and use systems like Permaweb Payment Protocol (P3) to pay for data access

So I looked into this Permaweb Payment Protocol (P3) Protocol in short ([ref](https://blog.arweave.net/)):
- Providers publish rates listing priced services and accepted tokens (the common service provided here is access to stored arweave data).
- A client chooses the cheapest and most responsive service providers, and pre-deposits funds to the provider’s wallet (on-chain), then signs each HTTP request with P3 headers identifying which deposit to charge.
- The provider keeps a local deposit ledger (we seem to trust providers here), returns 402 Payment Required when the deposit is empty. Settlement to the chain balances can be done the provider.
- Clients can then score providers based on reliability and responsiveness.

**Problem:** As a user how do I retreive my data? the protocol incentivizes nodes to respond to other storage nodes not to users! Users best option is to use centralized gateway or pay for access, meaning you pay for storage, then access.

**Problem:** centralization of access to the data since it goes through this gateway and most likely the gateway is caching all data, what's the point of miners!

### Replication or Erasure Coding
Arweave uses a different blockchain structure where each block is linked to two previous blocks (1) the really previous one, (2) randomly chosen old block. They use this randomness to ensure that nodes are storing old/history data so if you have the old block, you have more chance to mine the block and get rewards. They don't really seem to enforce or have any idea of how many replicas there are for a given block/data!! Based on the incentives, they assume nodes will store data. They say that nodes are incentivized to store **rare** data (data that only few nodes has) because they would have better chances of mining the block, but then how do you know which blocks are **rare**? appearently you don't, you can ask other nodes for the specific old data but this is not part of the protocol and nodes are not even incentiviced to respond (i keep rare data with me so i have better chances of mining next block). Ok there is the reputation system that they have but that doesn't solve this problem in my opinion. Additionally, for a new node joining, why would any other nodes share old blocks if it is incentivized to keep it rare?
New nodes join can get some of the old data if keeps watching new blocks, but I would assume new joiner would need to wait for very long time to construct old blocks. Another option is to use the gateway or pay for access.

What storage nodes end up doing is just replicate the entire data - as in all data in the network, they say:
> incentive-driven approach to maximising the number of redundant copies of any individual piece of data in the network.

but in reality, you as a node end up storing everything which could explain the 97% replication rate they mention. 97% seems too high, if you have lots of nodes that means most nodes are storing most if not all data in the network. To me this seems to be a huge overhead, too much wasted resources! is this even scalable?

**Problem:** full replication of entire data in the network to all nodes is NOT scalable.

**Problem:** As a user I don't really know who has my data and is it still there without asking lots of nodes. I don't know the state of my data, how many replicas of my data are there? what guarantees do you have for MY data not EVERYONE's data?

### The Data Blockchain

The blocks in the Arweave blockchain contain two types of data: token transactions, and data blobs (to be stored).

Each block contains a Merkle root of the current state. This root is the hash of the current block root + previous block root + recall block root. The block merkle tree contains again merkle roots of transactions as its leaves. The transaction Merkle tree contains yet again merkle roots of the data to be stored where the leaves are chunks of data (256 KiB chunks).

**Mining a block** requires new trasactions each containing token transfer or data blobs, as well as knowledge of a recall chunk. A recall chunk is a randomly chosen chunk of old data that the miner must use/know to generate a valid proof (see proof section for more info). So this design explains the pay upfront, you pay one time and data gets stored, later it is randomly checked as part of the block creation protocol.

**Packing:** They having this somewhat complicated mechanisim for "packing" which they use to ensure that each miner is actually storing a different replica of the data than other miners, so basically what this packing guarantees is that when a miner submits a proof that they have/know the data, that data/replica is unique and is tied to the miner's address. So this somewhat removes the ability of multiple miners generating proofs for just one replica stored on amazon for example. Another reason for packing is that it also ties the data/chunks to the specific block that includes that data, so if you have identical chunks but in different blocks, you can't re-use the proof (see proofs section on how proofs works). This might sound complicated by a typical flow with packing is:
- Users submit transactions that include the data root.
- Providers receive these transactions and data.
- Providers pack the received data so that they have their unique replica handy and quickly accessible (so what is stored is basically packed data, not plain data). Note that packing is CPU heavy (uses [RandomX](https://github.com/ArweaveTeam/RandomX)) so miners are discoraged from doing packing on-the-fly as it would make it less likely to mine the block -> pack in advance.
- When a mining block requires proofs on randomly chosen old chunk of data, provider fetches the packed chunk, generates a proof, and mines the block.
- Other peers receive the block with packed chunks, then unpack them (again CPU heavy), then re-pack them for their unique replica, and store.

Packing is required to receive the mining rewards, so the winning block contains packed data with an address that matches the reward address.

**Problem:** the packing technique is nice for ensuring unique replicas, but very CPU heavy.

**Data Bundling.** They discuss the ability to bundle data so instead of trasactions containing roots of data, it can contain roots of bundles of data which "bundling services" can merge multiple small data into larger bundles of data that are sent to the miners/providers. This is kind of outside of the protocol and packing and unpacking of these bundles is handled by the so-called "bundling services", I would also assume this carries some cost.

**DHT.** Arweave don't use a DHT, but rather a gossip protocol, and they use the same for ranking peers (for reputation).

### Proofs
In trying to figure out the type of proofs they use in Arweave, one can get lost in the confusing names they use and the many variants they discuss in different sources. It seems they started with Proof-of-access PoA, then Succinct Proof of Access (SPoA), and there is Succinct Proofs of Random Access (SPoRA). To be honest, I think these are all fancy names for Merkle proofs of randomly chosen leaves/chunks, but let's discuss the details.

In the original PoA (Yellow Paper), to build a new block you need a recall block and you must include its entire contents in the material that is hashed. That means you can’t search for a valid nonce (using RandomX PoW) unless you already have the recall block bytes. Verifiers recompute the BDS (given the recall block) to check your work. It’s not sampling data blocks, it’s whole block inclusion in the PoW input.
The flow for proving is:
- Miner picks a recall block based on current and previous block hashes.
- Miner builds the new block with new transactions, previous block hash, and recall block.
- Miner does the PoW with RandomX to find the nonce.
- Miner broadcast the new block.

Obviously, this approach was bad for many reasons and so they moved to SPoA.

In the recent version of Arweave that is described in the lightpaper, they use what they call "Succinct Proof of Access (SPoA)" which is somewhat strange name because it sounds like its a ZK proof but it's not, it is just a Merkle proof. They also call it Succinct Proofs of Random Access (SPoRA) in [ANS-103](https://github.com/ArweaveTeam/arweave-standards/blob/master/ans/ANS-103.md) and was [adobted in 2021](https://arweave.medium.com/the-arweave-network-is-now-running-succinct-random-proofs-of-access-spora-e2732cbcbb46). What this proof does is that since you have the data represented as Merkle tree and commitment (root) is included in the block, a challenge is generated and then the prover will have to prove knowledge of the specified chunk in the merkle tree. So this is basically sampling but they strangely don't call it that to make it sound fancy I guess!
The flow for proving is:
- The dataset is chunked (256 KiB chunks with an offset/index to identify the chunk) and build a Merkle tree on top of these chunks.
- Miners/providers pack (using the packing technique described earlier) these chunks and store them.
- When miners need to prove a recall block, they pick a recall chunk (not a block). They have a pretty complex function for which recall chunk you pick which includes a range and need to generate a nonce with RandomX.
- Miner read the packed chunk from its storage.
- Miner generates a Merkle proof (chunk -> data_root -> tx_root -> block_root)
- Miner includes the proof in the new block and publishes it.

### Private data
They have the simple approach of encrypting before upload which is basically the same as we were planning for in the original Codex. It is not part of the protocol and they recommend using AES-256-GCM/CTR.

## Sia
Sia seems to be rather an older system, their v1 started in late 2014 and looks rather outdated to me. Many of the concepts seems rather old-ish especially give how fast things move in web3/blockchain space.

Let's start with my sources of information (aside from [Leo's research](https://drive.google.com/drive/folders/19rvWWoT219Dyp1f4BJFqeJY3xMK-Lx7l?usp=sharing):
- The [2014 whitepaper](https://sia.tech/whitepaper.pdf) describes the original version of Sia but it is only recently in [June 2025](https://archive.sia.tech/sia-v2-a-fork-in-the-road-5d5e362bcd98) that this version got changed to v2.
- The [v2 wiki](https://sia.tech/learn), which describes the v2 version of Sia but not in a lot of detail.
- The [Sia docs](https://docs.sia.tech/).
- The [Sia Blog](https://archive.sia.tech/).

### Target Use-Cases
Sia is basically a marketplace connecting clients (called renters) and storage providers (called hosts). It's really general-purpose storage where the renter erasure-codes + encrypts data client-side and then makes many contracts in the marketplace with many independent hosts. The renter pays for both storage + bandwidth. It fits use cases where the renter really does everything to ensure data durability. So without the renter being an active, online participant in the system, durability is not guaranteed. If a use-case can tolerate such active participation, then yes Sia is a fit.

### The Sia Blockchain

Sia runs its own PoW blockchain somewhat similar to Bitcoin but with additional functionalities to manage the marketplace contracts. In Sia v2, consensus/tx formats and the renter-host architecture were overhauled for better performance and protocol flexibility. They adopted the UtreeXO instead of UTXO, so basically Merkle trees of UTXOs. See [here](https://lukechampine.com/utreexo.html) for more info on what they did.

No DHT for discovery or content.

### Incentives
Sia uses basic and somewhat familiar incentives:

**Storage incentive.** A payment for storing the data from the renter to host. At "ProofHeight" time which is about 24 hours before contract expiry, the host must submit a storage proof, If valid the host is paid, if missed the payment is **burned**, not returned to the renter so neither side profits from causing a miss. The reasoning behind this is kind of strange to me and doesn't make sense. They say they want to avoid malicious renters that DDOS the host so it cannot re

**Data retrieval/bandwidth incentives.** Hosts set a price for ingress/egress bandwidth, and renters pick hosts by price/uptime/latency/score (Sia seems to have a [scoreboard](https://siascan.com/) for this!).

**Collateral.** Hosts must post collateral to pay fees for storage proof tx which is done at the end of the contract. The collateral can also be used to keep the hosts honest.

**Problem:** durability depends on renter liveness. The renter must be online to: refill allowance (the storage cost can be filled over time not all at once), renew contracts (contracts can be short in time), and repair missing shards(responsibility is fully on the renter). If you go offline, durability is not really guaranteed.

### Replication / Erasure Coding
Sia uses Reed–Solomon erasure coding in the following way:
1. Split file into 40 MB chunks (small files are padded so I'm assuming minimum storage file size is 40MB).
2. For each chunk, Reed–Solomon to generate 30 pieces each 4MB (10 data + 20 parity), i.e. any 10 of 30 can reconstruct.
3. Encrypt each of the 30 pieces and upload each to a distinct host.

Sia encrypts **after EC** not before. This means you have 3x increased cost of encryption (i.e. instead of encrypting 40MB you encrypt 120MB chunks). It also means hosts cannot reconstruct the data and therefore, reconstruction is not part of their role and only the renter can reconstruct. Again as I said earlier, this means the renter is fully resposible for durability, it has to check regularly on the data and reconstruct if needed. The renter is supposed to keep a log of "file health" (reminds me of Ben's constellations). I feel like all this overhead on the renter makes you question if it is even worth it to off-load storage! might as well just store the data locally.

The reason they mention for this design choice is that this prevents lazy hosts from reconstructing the data on-the-fly instead of storing the data. In other words, if a host knows that there are 29 other hosts storing that data and he only needs 10 of them to reconstruct + the proof is only submitted at the end of the contract, he can just reconstruct it then and avoid storing. This is a reasonable logic i guess but again means only the renter can reconstruct.

### Proofs
The Sia storage proofs are just simple Merkle proofs, one for each of the 4MB pieces in the 120MB (120MB is the 40MB after EC) chunks (remember these 4MB are not erasure coded). A Merkle tree is constructed on each 4MB and then the host submits a Merkle proof for a 64-byte leaf. If valid -> host receive storage payment, if NOT valid -> payment and collateral are burned. Only **ONE** single proof is submitted per 4MB at the end of the contract.

**Flow:**
1. Create contract (payment, collateral, Proof/Expiration, data_root, access/upload/download price).
2. Contract Revisions: during the contract term (uploads/downloads changes balances), or extend.
3. At "ProofHeight" or 24 hours before expiry, host submits proof tx, if included -> host paid.
4. If proof is missed after the expiration date the payment & collateral coins get destroyed.

### Privacy
All pieces are **client-side encrypted** (current v2: ChaCha20, old: [Threefish](https://en.wikipedia.org/wiki/Threefish)), with per-piece/chunk keys derived from renter secrets. As mentioned earlier, the renter encrypts after EC, meaning 3x overhead on encryption. It also means that to reconstruct, the user will have to decrypt -> reconstruct -> encrypt -> send to hosts.

## Storj
To be added ...