The Motivation Behind Arion, and What's Wrong with IPFS
When we set out to build Hippius, the obvious path was to build on IPFS. It's the default for decentralized storage. Everyone knows it. It has a large ecosystem.
So why start from scratch? Because IPFS has fundamental limitations that make it unsuitable for production storage. We built Arion, our own distributed storage engine, to solve them. This post explains the reasoning and the architecture.
The core problem with IPFS in production
IPFS is a great proof of concept for decentralized storage. For production workloads, it has a fundamental problem: you don't know where your data is.
When you store a file on IPFS, the network uses a Distributed Hash Table (DHT) to track which nodes have which content. To retrieve a file, you broadcast a query across the network: "Who has hash QmX...?" Nodes relay the query until someone responds.
This works fine for small files and low-stakes use cases. It breaks down when you need low latency (DHT lookups take hundreds of milliseconds to seconds), guaranteed availability (nodes come and go, and IPFS doesn't self-heal), predictable retrieval (retrieval time is non-deterministic), or production SLAs (IPFS has no built-in durability guarantees).
The latency problem alone is a dealbreaker for S3-compatible storage. A video streaming app can't afford 800ms to discover where the first chunk lives.
The Arion approach: "Don't ask. Compute."
Arion eliminates the discovery phase entirely.
Instead of asking "who has this file?", we calculate the answer.
Here's how it works:
File location = CRUSH(Hash(file), Cluster Map)
The Cluster Map is a live blueprint of all active miners, their storage capacity, and their reputation scores. It's published directly to the Hippius blockchain. Anyone with the latest cluster map can compute exactly which nodes hold any given file, locally, in microseconds.
No network queries. No DHT hops. Just math.
This transforms the storage network from a "search engine" into an "addressable memory space". Time to first byte drops from hundreds of milliseconds to the raw network transit time.
Because the calculation is local, the network keeps working even if the validator goes offline. As long as you have the latest cluster map from the chain, you can retrieve your data.
The CRUSH algorithm
Arion uses a modified implementation of CRUSH (Controlled Replication Under Scalable Hashing), the same algorithm that powers Ceph, the storage backend used by CERN, Deutsche Telekom, and major cloud providers.
We added one key innovation: Placement Groups (PGs).
Instead of mapping every individual file to specific miners (which doesn't scale to 39 million files), we:
- Map each file to a Placement Group:
PG_ID = Hash(file) % PG_count - Map each Placement Group to a set of miners:
Miners = CRUSH(PG_ID, Cluster_Map)
This means when a new miner joins the network, we only need to rebalance a small percentage of Placement Groups, rather than recalculating the location of 39 million files.
Cabal resistance
We also added a Hybrid Weighted Selection model to prevent network centralization:
Node weight = Storage Capacity × Reputation Score
The Reputation Score is earned over time based on uptime, successful audit challenges, and node age. A malicious actor can't spin up a massive server farm and instantly capture network traffic. Trust must be earned. New nodes start with low weight and build reputation over time.
Erasure coding: surviving 66% node loss
IPFS-based systems typically replicate data 3-5x across nodes. This is simple but inefficient: storing 1 GB requires 5 GB of network capacity, and if more than N-1 copies are lost, the data is gone.
Arion uses Reed-Solomon erasure coding instead.
Every file is split into 30 shards: 10 data shards + 20 parity shards. These are distributed across 30 independent miners. To reconstruct the file, you only need any 10 of those 30 shards.
The math:
Fault tolerance = 20/30 = 66%
The Hippius network can lose 66% of its storage nodes simultaneously and your data remains 100% intact. For comparison, a 3x replication scheme fails if you lose just 2 copies.
Storage overhead is also lower. With 5x replication, you use 500% of raw storage. With our 10+20 erasure coding scheme, you use 300%, and get dramatically better fault tolerance.
Topology awareness
Arion enforces a topology constraint: no two shards of the same file can be placed on nodes in the same "failure domain" (same rack, same datacenter, same autonomous system). If an entire datacenter goes offline, at most one shard per file is affected, well within the recovery threshold.
The immune system: active self-healing
Surviving node failures is necessary. But Arion goes further: it recovers automatically.
The validator continuously monitors shard health across the network. When it detects a degraded shard (node offline, disk failure, or failed audit), it:
- Downloads any 10 healthy shards from the network
- Mathematically reconstructs the missing shard
- Uploads the regenerated shard to a healthy replacement node
- Updates the cluster map on-chain
This happens without any user intervention and before the failure becomes critical. The network repairs itself the way biological tissue heals, staying ahead of degradation at all times.
Grid Streaming: parallel retrieval
One more piece. When you request a file from Hippius, the Gateway doesn't download shards sequentially. It opens concurrent QUIC streams to multiple miners simultaneously, assembling the file in parallel.
This is what we call Grid Streaming. The practical result: aggregate bandwidth that can exceed what any single server can provide. A file stored across 30 nodes in different locations downloads faster than a file from a single centralized server, because all 30 connections transfer simultaneously.
The result
| IPFS | Traditional Replication | Arion | |
|---|---|---|---|
| Content discovery | DHT search (O(log N)) | Centralized index | Computed locally (O(1)) |
| Fault tolerance | Best-effort | 2 node failures (3x rep) | 20 node failures (10+20 EC) |
| Storage overhead | Variable | 300-500% | 300% |
| Self-healing | No | Depends on provider | Yes, automated |
| Validator dependency | Required | Required | Optional (client can compute) |
Arion is what allows Hippius to offer S3-compatible storage that's genuinely production-ready: real infrastructure you can build on, tested at scale.
Technical deep-dive
Want more detail? The full Arion technical paper is available on our community forum: Hippius Arion Technical Paper
Get started
- Storage docs: docs.hippius.com
- S3 quickstart: hippius.com/blog/hippius-s3-drop-in-replacement
- Console: console.hippius.com
- Become a miner: docs.hippius.com/earn/arion/running-blockchain-node