website logo
Create accountLogin
Home
DCS
Node
Resources
Help center
Navigate through spaces
Home
DCS
Node
Resources
Help center
⌘K
Storj DCS
Get Started
AWS CLI and Hosted Gateway MT
AWS SDK and Hosted Gateway MT
Uplink CLI
Satellite Admin Console
Object Browser
Downloads
Download Uplink CLI
Download Self-hosted S3 Compatible Gateway
Download Storj Client Libraries
SDKs & Reference
Tutorial
How-to Guides
Concepts
Support
Support Overview
FAQ
Community Forum
Status Page
Help Desk
Billing, Payment & Accounts
Resources
Moved Documents
Docs powered by archbee 
5min

Coordination Avoidance

Rather than coming to a global consensus around the entire state of the network (as in blockchains like ethereum, etc.) The Storj Network is Coordination Avoidant. The network does not need global consistency (as per CAP Theorem) as each uplink user only needs to be able to recover their files.

Advantages Over Coordination-dependant Systems

By ensuring coordination avoidance within Storj DCS, we’re able to deliver better performance and scalability over other decentralized systems—two issues that are critical to achieving broad adoption with traditional storage users. Decentralized systems that are coordination dependent, like Bitcoin, require an increasing number of resources as they scale. To compete with centralized cloud storage platforms like Amazon S3, Microsoft Azure, and Google Cloud, Storj DCS must be able to scale into the exabyte range, and beyond—something we feel confident it will be able to achieve.

We believe our approach of decentralizing both storage and metadata tiers in the network allows greater scalability, performance, and reliability than systems that rely on seeking consensus.

Comparison to Blockchain Networks

Blockchain consensus offers very strong guarantees, but this comes at a heavy cost in coordination overhead. Coordination is not always necessary for correctness and minimizing coordination is key to maximizing scalability, availability, and high performance in database systems. One fundamental design decision of the Storj network was not to utilize blockchain consensus for file transfers to increase those properties of the Storj network. Storj takes a pragmatic approach to avoiding blockchain consensus while still maintaining correctness for file transfers. But, at the same time by default, Storj uses blockchain consensus with the Ethereum-based STORJ token for payment processing to storage node operators.

Storj DCS is an enterprise, production-ready version of the Storj network, complete with guaranteed SLAs. All user uploads and downloads on Storj DCS uses metainformation from Storj DCS Satellites which are special nodes on the network that audit storage nodes and ensure Storage Nodes properly storing files and managing metadata for users storing data on the network.

Document image

As shown in the above architecture, there are three primary peer classes within the Storj network. All are open source, and capable of being run by any third party, making the network architecture fundamentally decentralized.

The Storj network can leverage the decentralized nature of storage nodes and Satellites to create partitions in the network to isolate users and file transfers from each other, which helps minimize coordination across the Storj network. For extremely high throughput demands, organizations can run their own Satellite. This avoids coordination overhead with the rest of Storj DCS and allows users to make their own decisions about what database infrastructure their Satellite will use and relax consistency guarantees if they wish.

Updated 12 Aug 2022
Did this page help you?
Yes
No
UP NEXT
File Redundancy
Docs powered by archbee 
TABLE OF CONTENTS
Advantages Over Coordination-dependant Systems
Comparison to Blockchain Networks