Storj предоставляет S3-compatible object storage поверх распределённой сети независимых дисков. Клиент шифрует данные, делит их на segments, применяет erasure coding и отправляет pieces множеству storage nodes. Координационный Satellite знает, где лежат части и когда их ремонтировать, но не получает ключ расшифрования.
Что именно децентрализовано
Storage nodes принадлежат разным операторам и находятся в десятках стран. Они хранят зашифрованные pieces, обслуживают download и отвечают на audits. Узел не видит имя файла, его полный состав или encryption key.
Satellite отвечает за account, metadata, node discovery, reputation, billing, audit, repair и payouts. Пользователь доверяет выбранному Satellite доступность метаданных и правильную координацию. Это не полностью permissionless протокол, где любой consensus автоматически заменяет оператора. Любой может развернуть собственный Satellite, но production-сервис требует сложной инфраструктуры.
По этой причине Storj отличается от permanent storage в Arweave и рынков сделок хранения в Filecoin. Он ближе к облачному object storage с распределённым data plane и управляемым control plane.
Uplink и client-side encryption
Приложение использует Uplink library, CLI или S3 gateway. До upload клиент шифрует содержимое и metadata. По умолчанию поддерживается AES-256-GCM. Satellite получает API key и сведения, нужные для маршрутизации, но не encryption passphrase.
Access Grant объединяет адрес Satellite, ограниченный API key и path-based encryption key. Из parent grant можно вывести более узкий child grant: только чтение, определённый bucket, prefix или временное окно. Потомок не может получить больше прав, чем родитель.
Такая модель уменьшает доверие к оператору storage, но переносит ответственность на пользователя. Потерянную passphrase Storj не восстановит. Передача полного Access Grant третьему лицу фактически передаёт предусмотренные им права и возможность расшифрования.
Erasure coding и распределение pieces
Крупный объект разбивается на segments по 64 MB. После шифрования применяется Reed-Solomon erasure coding. В актуальном описании immutable storage используется схема 29/110: создаются 110 pieces, а для восстановления достаточно 29 доступных частей. Конкретные параметры могут зависеть от segment и версии сервиса, поэтому их нельзя превращать в универсальное обещание для любого продукта.
Pieces распределяются между независимыми nodes с учётом subnet, географии, производительности и reputation. Одновременная загрузка параллельных частей даёт хорошую скорость даже без мощного отдельного сервера. Клиент прекращает ждать лишние pieces, когда набран достаточный набор для decode.
Audits, reputation и repair
Satellite статистически запрашивает небольшие диапазоны сохранённых pieces. Успешный audit подтверждает, что node действительно держит данные. Ошибки снижают audit score; длительная недоступность влияет на online score. Ненадёжный node может быть suspended или permanently disqualified для конкретного Satellite.
Когда доступных pieces становится меньше repair threshold, Satellite загружает достаточный набор, повторно кодирует segment и распределяет новые части healthy nodes. Поскольку данные остаются зашифрованными, repair service не получает содержимое.
Эта система заменяет blockchain consensus для вопроса хранения. Ledger не нужен, чтобы постоянно записывать каждый audit. Клиент доверяет логике Satellite, а durability обеспечивают redundancy, независимость nodes, audits и repair.
Экономика storage node
Оператор предоставляет свободное место и bandwidth. Он получает оплату за фактически сохранённый объём, customer egress и repair traffic по действующим ставкам соответствующего Satellite. Наличие большого пустого диска не гарантирует заполнение: новый node сначала проходит vetting и конкурирует за реальный customer demand.
Upfront stake не требуется. В первые девять месяцев Satellite удерживает часть начислений, постепенно снижая процент. После пятнадцатого месяца половина накопленного held amount возвращается, а остаток выплачивается при успешном Graceful Exit. Резкий уход может привести к потере удержанной части для покрытия repair.
Выплаты обычно производятся ежемесячно в STORJ через Ethereum или поддерживаемую L2 с учётом minimum payout threshold. Точные rates и threshold меняются и определяются текущей payout policy, а не историческими калькуляторами окупаемости.
Токен STORJ
STORJ – ERC-20 utility token. Им можно пополнять баланс storage account, а node operators получают в нём выплаты. Клиент также может платить картой или invoice, поэтому спрос на storage не превращается автоматически в покупку токена каждым пользователем.
В существовании находится около 425 млн STORJ. Это результат token sale, company-held balances и прошлых burns, а не продолжающийся mining. Storj публикует quarterly Token Balances and Flows Reports, поскольку движение company-controlled запасов влияет на circulating supply.
STORJ не является governance token протокола и не даёт долю в Storj Labs. Возможное участие holders в капитале после реструктуризации 2026 года является лишь заявленным предложением, которое требует court approval и окончательных документов.
История
Storj появился в 2014 году из идеи Shawn Wilkinson использовать свободные диски для более дешёвого и приватного cloud storage. Ранние версии и Counterparty-токен были заменены архитектурой Storj V3 и ERC-20 STORJ. Production-сеть сделала упор на object storage, client-side encryption и Satellites.
В 2024 году компания расширила distributed cloud через acquisitions compute и file-access продуктов, а Colby Winegar стал CEO. В октябре 2025 года Storj объявила соглашение о присоединении к Inveniam при сохранении network и token utility.
26 июля 2026 года management и board начали добровольную court-supervised financial restructuring для урегулирования legacy liabilities. На момент официального объявления сеть, сервис и выплаты продолжали работать. План дать token holders механизм участия в equity реструктурированной компании остаётся намерением, а не действующим правом.
Команда
Основатель Shawn Wilkinson сформулировал первоначальную архитектуру. Текущую компанию возглавляет CEO Colby Winegar. В руководстве также указаны CFO Dorrie Chung, Chief Architect JT Olio, CTO Jacob Willoughby и другие операционные руководители. Storj остаётся отдельным юридическим и операционным бизнесом в экосистеме Inveniam.
Применение
Storj подходит для backups, media assets, software distribution, research datasets и S3 workloads, которым нужны geographic distribution и predictable object API. Он не заменяет database с частыми мелкими транзакциями и не обещает permanent retention без оплаты.
В отличие от indexing layer вроде The Graph, сервис хранит сами objects, а не отвечает на структурированные blockchain queries. Разработчик должен отдельно продумать database, lifecycle, versioning и recovery ключей.
Основные риски
- Satellite trust. Control plane, metadata и billing концентрируются у выбранного оператора.
- Потеря ключа. Client-side encryption исключает восстановление passphrase службой поддержки.
- Node churn. Массовый уход операторов увеличивает repair load и может повредить доступности.
- Экономика оператора. Диск заполняется только при спросе, а bandwidth, electricity и hardware failure уменьшают результат.
- Token volatility. Выплата в STORJ меняет фиатный результат между начислением и продажей.
- Company concentration. Большинство production Satellites и product decisions связаны со Storj.
- Финансовая реструктуризация. Court process создаёт неопределённость для компании, contracts и holders, хотя network продолжает работать.
- Юридические данные. Географическое распределение pieces не отменяет требований residency, retention и compliance.
Итог
Storj решает задачу distributed object storage инженерными средствами: encryption, erasure coding, reputation, audit и repair. Его архитектура уменьшает доверие к отдельному диску и скрывает данные от nodes, но сохраняет важную роль Satellites и компании. В 2026 году техническую жизнеспособность нужно оценивать отдельно от корпоративной реструктуризации и спекуляций о будущем статусе token holders.
