How do you resolve the location? Just like you have a URL or a link of a website, you start with the hash identifier of the resource. You send around a request for anyone with the resource with this identifier. On success will respond, access it peer-to-peer. The hash is the key, the key, value pair, and the value is the location of the file or the resource. The routing part of the IPFS protocol maintains distributed hash table or DHT for locating the nodes as well as the file objects. A simple DHT holds a hash as the key, location as the value. A key can directly map onto the location stored in DHT. Now that we have located the node and the location of the object, how do we exchange the blocks of the file? In a typical IPFS system, DHT resolves the closest location to the key-value. The peer node holding the data blocks are incentivized by a protocol called bit swap. Peer nodes have a want list and a have list, and some form of barter system is formed. The want list is a list of all objects that node wants, and have list is a list of all objects it has available in its position for sharing with others. Any imbalance is noted in the form of a bit swap credit or debt. Bit swap protocol manages the block exchanges involving the nodes accordingly. The nodes of the network does have to provide a value to the network in the form of blocks. Do you see that this could be an ideal use case for a digital token? If you send a block, you get an IPFS token that can be used when you need a block. A bit swap protocol has provisions where handling exceptional situation such as freeloading nodes, and nodes wanting nothing, nodes having nothing, and so on. How a multiple versions of files maintain? Multiple versions of a file are maintained using Merkle directed acyclic graph data structure on top of the file system. The basic elements of a version are: the block, list of blocks, tree of blocks representing the file instance, and the commit that is the snapshot of the tree. This Merkle then also helps to check for any tampering and also to avoid any file duplication. You can observe two commits and of course four directory, for nodes on the left from the first commit, and the three nodes on the right the second commit. This is a dag instead of a Merkle tree we saw in etherium state route. You can also observe the duplication of the Hello World file here. It means that the file is shared between two commits, you see two shared files in this picture. What are the use cases of IPFS, and how about the relationship to the blockchain decentralized system? IPFS can be a stand-alone decentralized file system. It can be complimentary to the existing HTTP based centralized system. We discussed IPFS in the context of blockchain system because it can serve a significant role of decentralized storage for blockchain application that have a lot of data. In this case, the volume and this data can be stored on the IPFS and its metadata on the block chain. In this case, it's of a centralized store. IPFS can be the store that works in tandem with a decentralized ledger technology of the blockchain to create a powerful solution for many storage rich business use cases. We discuss the details of a decentralized storage system that can be used for storing the off chain data for the blockchain. It is used in many genomic data application for storing large genomic data and in dApps such as open law for document storage
