Intro

This document presents the DSN v3 overview for the Subspace Consensus v2 and contains the best current design. DSN v3 is the successor of DSV v2.

DSN v2 architecture has significant problems that prevent the network from scaling well. When the network hit 1-2k peers it begins to struggle with acquiring new pieces. The reason for that is that it hits connection limits on the peers. Piece publication and acquisition require a new connection for each piece to some random peer closest (by its PeerID) to the piece index hash. All the nodes regularly publish 256 pieces for each new archived segment and with farmers publishing their pieces from the archival layer (plot) network peers experience constant connections and reconnections from random peers and their connection queue always hit the predefined connection limit. But we can’t increase connection limits for a couple of reasons, e.g.:commodity routers begin to experience problems. The root issue lies with the piece's publication strategies and the next DSN version 3 seeks to resolve this issue.

Most previous concepts from DSN v2 are still relevant. We keep a layered network structure with archival storage (L1), piece cache (L2), and object cache (L3) with the same peer types (nodes, farmers, bootstrap-nodes) and so on. We eliminate the piece publication process by changing how we populate the L2 cache and process L2 cache misses.

The initial source of the pieces in the DSN is the nodes archiving segments. Previously (DSN v2), we published the new pieces using Kademlia by deriving piece indexes from segment indexes and connecting with closest peers to the piece index hash from peers’ PeerID. Peers receiving this publication (with the closest PeerId to the piece index hash) would download the piece and announce the piece back to the Kademlia network.

Known limitations

• Security concerns are left to the next revision.
• This document omits DSN parts related to object mappings and object retrieval.

Peer types

• node - a blockchain consensus node. It produces blocks, archives segments, and produces pieces.
• farmer - a blockchain consensus node, it stores pieces in encoded form in sectors.
• bootstrap-node - serves for the initial network bootstrapping
• client - an external DSN user

Network layers

Object cache layer (L3)

Note: object cache design needs to include object mappings solution and be finalized.

Pieces cache layer (L2)

There is a way to notify farmers about the new segment without Kademlia by receiving the segment index from the latest block header from the connected node. On receiving the new segment index, farmers will derive the piece index hashes from the segment index and compare their PeerId with those hashes to determine whether they should download it locally to L2. If there are pieces to download farmers connect to the connected node via RPC and download the required pieces to its L2.