SWARM Explained

Share it with your followers

WHAT’S SWARMING?

Swarm forms the basis of the Ethereum network by providing a storage and distribution centre for data that is shared across Ethereum. Swarm is free of censorship and provides incentives to the nodes which pitch in their bandwidth and storage facilities. Whenever a node uploads some data over Swarm, it is broken up into parts called chunks. This chunking process is carried out by the chunker which basically divides the data into small pieces. The current Swarm Network has a Tree Chunker which divides the data in the form of a data tree. Whenever data is uploaded over Swarm, the chunker divides it in a way such that it forms a tree structure. This structure can then have leaf-nodes and branching nodes. The leaf nodes contain actual subslice of data whereas a branching node contains the hashes of all its children. Basically, the chunker is your most-impartial and fair pizza slicer.
The root-to-leaf branches should be of equal length (balanced) but the rightmost branch can be smaller than the rest. No two chunks of data can have the same hash and this makes sure that data integrity is maintained.

Syncing is a process that is carried out over Swarm that makes sure that once the data has been uploaded, it moves closer to the nodes which lie near the chunk addresses. These nodes then not only serve the content but also store it! The chunk moves from node to node till it arrives at a node whose address is closest to the chunk hash. This makes the retrieval of data easier. On top of that, each node has a chunk syncer which propagates chunks further so that they can lie closer to the chunk hash.

SPACE: It matters in relationships and networks alike

Swarm makes sure that there is an effective utilisation of space. Whenever a new chunk enters the network, it is moved to the node which is closest to the chunk hash and stored there alongside old chunks. The oldest chunks are deleted if there is a shortage of space and this makes sure that chunks which are readily accessed stay in place. When a retrieval request comes in for a particular chunk, the concerned node sends the chunk back through the same route. All the intermediate nodes on this route also save a cached copy of the chunk once the original one has been received by the receiver. This makes sure that popular content can be delivered by multiple nodes, thus reducing network traffic.\

INCENTIVES WORK!

The Swap feature of Swarm makes it profitable to store and deliver content. Basically, nodes can trade chunks-for-chunks or chunks-for-payment. This means that nodes which store and make the data available for everyone get the payment or other chunks while the ones which download data must pay for it. This makes sure that Swarm remains a self-scaling system and popular content is readily available, reducing latency and network traffic. It is not necessary that all chunks are of equal value. In case the serving node is doing the served node significant favour and the payment threshold is reached, then the serving node can ask for payment from the served node. In case the served node becomes highly indebted and disconnection threshold is reached, the served node simply becomes disconnected. This makes sure that all nodes try to exchange valuable content and not be free-loaders. The payment takes place through a chequebook based on Blockchain technology.

Another mechanism of Swarm is the Swear. It tackles the ‘upload and leave’ problem faced by multiple nodes over networks. Basically, a node can upload data once and then keep it preserved even if it’s not famous. He can pay other nodes, which are registered by Swear, to ensure that they will store the data for a given amount of time even if it is not popular at all. The Swear mechanism makes sure that the responsible nodes are held accountable if they lose the data before their contract expires.

An important mechanism to make sure that nodes which are registered with Swear actually store chunks is that of Swindle. In case a challenging node feels that the storing node has lost some data it was supposed to protect, it can issue a challenge. The challenge is issued by sending the receipt of the data with some payment (to avoid bogus challenges) to the Swindle contract. The node responsible for storing the data then has to refute the claim by presenting the chunk of data. The contract confirms if the hash of the presented chunk is the same as that mentioned in the receipt presented by the challenger. If the challenger stands proven then litigation is carried out against the node which was supposed to keep the data stored. This litigation might also come in the form of cancellation of storing the node’s registration.

Leave a Reply

Your email address will not be published. Required fields are marked *