status-im
/
dagger-research
mirror of https://github.com/status-im/dagger-research.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
dagger-research/evaluations/storj.md

2.5 KiB
Raw Permalink Blame History

An evaluation of the Storj whitepaper

2020-12-22 Mark Spanbroek

https://storj.io/storjv3.pdf

Goal of this evaluation is to find things to adopt or avoid while designing Dagger. It is not meant to be a criticism of Storj.

Pros:

  • Performance is considered throughout the design
  • Provides an Amazon S3 compatible API (§2.4)
  • Bandwidth usage of storage nodes is aggressively minimized to enable people with bandwidth caps to participate, which is good for decentralization (§2.7)
  • Erasure codes are used for redundancy (§3.4), upload and download speed (§3.4.2), proof of retrievability (§4.13) and repair (§4.7)!
  • BIP32 hierarchical keys are used to grant access to file paths (§3.6, §4.11)
  • Ethereum based token for payments (§3.9)
  • Storage nodes are not paid for uploads to avoid nodes that delete immediately after upload (§4.3)
  • Proof of Work on the node id is used to counter some Sybil attacks (§4.4)
  • Handles key revocations in a decentralized manner (§4.4)
  • Uses a simplified Kademlia DHT for node lookup (§4.6)
  • Uses caching to speed up Kademlia lookups (§4.6)
  • Uses standard-sized chunks (segments) throughout the network (§4.8.2)
  • Erasure coding is applied after encryption, allowing the network to repair redundancy without the need to know the decryption key (§4.8.4)
  • Streaming and seeking within a file are supported (§4.8.4)
  • Micropayments via payment channels (§4.17)
  • Paper has a very nice overview of possible attacks and mitigations (§B)

Cons:

  • Mostly designed for long-lived stable nodes (§2.5)
  • Satellites are the gateway nodes to the network (§4.1.1), whose requirements for uptime and reputation lead to centralization (§4.10). They are also a single point of failure for a user, because it stores file metadata (§4.9).
  • Centralization is further encouraged by having a separate network of approved satellites (§4.21)
  • Clients have to actively perform for audits (§4.13) and execute repair (§4.14) (through their trusted satellite)
  • The network has a complex reputation system (§4.15)
  • Consecutive micropayments are presented as a solution for the trust problems while retrieving (§4.17), which doesn't entirely mitigate withholding attacks.
  • Scaling is hampered by the centralization that happens in the satellites (§6.1)
  • The choice to avoid Byzantine distributed consensus, such as a blockchain (§2.10, §A.3) results in the need for trusted centralized satellites