Exploring the IPFS Protocol and its Integration with NFTs

By akohad Jan5,2024

[ad_1]

The IPFS protocol finds application in the realm of NFTs for storing not only metadata associated with the NFT but also the images themselves. To illustrate this in a practical context, let’s consider a tangible example of an NFT, such as the card featuring football player Messi in the fantasy game Sorare

If we check the section token details we can find these informations:

The Token ID directs us to Etherscan, providing access to the contract’s details and its source code. Being an NFT, it adheres to the ERC-721 standard.

Then we can see that the metadata and the picture related to the NFT are hosted on IPFS and from the link we can uderstand that both have been hosted on Pinata Cloud that offers a service of IPFS gateway.

The picture hosted on IPFS was the one showed before, while the metadata associated to the NFT are these:

{
"description": "Sorare Football Fantasy NFT collection",
"image": "ipfs://QmNdeKuZZYn9kswVc9e5AP5F7HJNJWpeAsLsvzpK5Npajg",
"attributes": [
{
"trait_type": "edition",
"value": "classic"
},
{
"trait_type": "player_age",
"value": 35
},
{
"trait_type": "player_birth_date",
"value": "1987-06-24"
},
{
"trait_type": "player_blockchain_id",
"value": "25231422346618897466161184991066014710242912075232564827261144631247649555194"
},
{
"trait_type": "player_blockchain_name",
"value": "Lionel Andrés Messi Cuccittini"
},
{
"trait_type": "player_country",
"value": "ar"
},
{
"trait_type": "player_kit",
"value": "home"
},
{
"trait_type": "player_name",
"value": "Lionel Messi"
},
{
"trait_type": "player_position",
"value": "forward"
},
{
"trait_type": "player_shirt_number",
"value": 10
},
{
"trait_type": "scarcity",
"value": "rare"
},
{
"trait_type": "season",
"value": 2023
},
{
"trait_type": "serial_number",
"value": 50
},
{
"trait_type": "team_blockchain_id",
"value": 72
},
{
"trait_type": "team_city",
"value": "Miami, Florida"
},
{
"trait_type": "team_country",
"value": "us"
},
{
"trait_type": "team_international",
"value": false
},
{
"trait_type": "team_name",
"value": "Inter Miami"
},
{
"trait_type": "team_year_founded",
"value": "2018"
}
]
}

The primary reason behind storing NFT images and metadata on the IPFS protocol is its cost-effectiveness compared to blockchain storage. Given the crucial role played by the IPFS protocol in hosting vital information about our NFTs, delving into its workings becomes essential.

Before we delve into the intricacies of the IPFS protocol, let’s explore the two predominant system architectures widely embraced globally: client-server and peer-to-peer.

The inception of the client-server model traces back to ancient times, serving as a foundational structure. Within a client-server architecture, fundamental to the HTTP protocol, data is centralized on servers, with access determined through location-based addressing (IP).

In contrast, the peer-to-peer architecture distributes data across multiple computers or peers, constituting a decentralized storage network. This architectural paradigm emerged to meet the demand for transferring large volumes of data, particularly in audio or video formats, areas where HTTP was not originally designed to efficiently handle such magnitudes.

IPFS stands for InterPlanetary File System and is a protocol and a peer-to-peer network for storing and sharing data in a distributed file system, where each file and all the blocks within it are identified by a unique fingerprint called cryptographic hash.

In fact each peace of content in IPFS is identified by a unique hash derived from its content, therefore the data is addressed by its hash (content addressing) rather than by its location (as in the HTTP protocol), such as an IP address (location addressing).

The three key responsibilities of the IPFS protocol are:

  • Representing and addressing data
  • Routing data
  • Transferring data

The peer-to-peer network is composed by multiple IPFS nodes, which are just applications executed on a physical machine.

IPFS enables users not just to receive but also to host content, resembling the approach used in BitTorrent. Unlike a centrally located server, IPFS is structured on a decentralized system of user-operators, each holding a segment of the entire data. This design establishes a robust system for file storage and sharing.

Any user within the network can share a file through its content address, and fellow peers can locate and request that content from any node possessing it by utilizing a distributed hash table (DHT), which stores the informations about the location of content on the network. When a node wants to retrieve content, it asks the network for the nodes that are closer to the content’s hash and requests the content from them.

Content in IPFS is immutable, meaning that once it is added to the network, it cannot be changed. Every change to a file or directory creates a new version, and the old versions are still accessible.

In IPFS, the fundamental data entity is referred to as a block. The data undergoes segmentation into blocks, each of which is allocated a distinct identifier known as a Content Identifier (CID). This CID serves as the address to point to the data, determined by the content itself, as opposed to the location. The CID is generated by merging the data’s hash with its codec.

This content-based addressing ensures that the content is immutable. If the content changes, its hash changes, creating a new distinct entry in the network.

CIDs are unique to the data they were derived from, offering IPFS the following advantages:

  1. Retrieval of data is possible based on its content rather than its specific location.
  2. The CID of the received data can be calculated and compared to the requested CID, ensuring that the data matches the expected content.

IPFS aims to tackle the issues present in the current web and protocols for data representation, routing, and transfer, such as HTTP, that include:

  • Verifiability
  • Resilience
  • Centralization
  • Performance
  • Link rot
  • Data sovereignty and ownership
  • Off-chain storage
  • Local-first software
  • Vendor lock-in

A cryptographic hash is a function that takes some arbitrary input (the content) and returns a fixed-length value. The exact same input data will always generate the same hash as output. You can find one here.

IPFS makes use of cryptographic hashes to authenticate and ensure the integrity of files, creating a formidable barrier against tampering or deletion by malicious entities.

IPFS eliminates the presence of a single point of failure, and there’s no requirement for mutual trust among users. In simpler terms, if one or even multiple nodes in the network fail, it doesn’t impact the overall functioning of the entire network. An IPFS node can retrieve data from the network as long as at least one other node within the network possesses that data, irrespective of its location.

IPFS stands as an open, distributed, and collaborative network that diminishes data silos associated with centralized servers, rendering it more robust compared to traditional systems. IPFS is not under the control, management, or ownership of a singular entity or individual. Instead, it is a community-driven project featuring various implementations of the protocol, a range of tools and applications utilizing the protocol, and diverse users and organizations actively contributing to its design and development.

IPFS accelerates data access by facilitating replication and retrieval from multiple locations. Users can access data from the closest location using content addressing instead of relying on location-based addressing (like the HTTP protcol). Essentially, because data can be addressed according to its content, a node within the network can retrieve that data from any other node possessing it, mitigating performance issues like latency.

Link rot refers to the inclination of hyperlinks, over time, to stop pointing to their intended file, web page, or server. This occurs due to the relocation of the resource to a new address or the resource becoming permanently unavailable.

IPFS resolves this issue by enabling data to be addressed by its content rather than its location. In essence, content within IPFS remains accessible regardless of its physical location and is not contingent on specific servers being available.

Data sovereignty pertains to the concept that individuals or organizations possess control over their own data and the capability to decide who has access to and can use it.

IPFS protects data sovereignty by allowing users to store and retrieve data directly from a decentralized network of nodes, as opposed to centralized third-party servers. This removes the necessity for intermediaries to oversee and govern data, granting users complete control and ownership of their data.

Off-chain storage involves storing data outside of a blockchain for data processed by the blockchain. It is employed to store large amounts of data that would be infeasible to store directly on a blockchain, thereby enhancing scalability and efficiency.

IPFS enables verifiable off-chain storage by creating a link between blockchain state and content-addressed published to IPFS. This is achieved by storing the Content IDentifier (CID).

Local-first software describes a type of software where data is stored and processed locally, and subsequently synchronized and shared with other devices when a network connection becomes available. By prioritizing local data storage, local-first software diminishes reliance on internet connectivity and underscores principles of data sovereignty and privacy.

IPFS enhances local-first software by offering a performant, decentralized, peer-to-peer data addressing, routing, and transfer protocol that prioritizes data storage and processing on individual devices. Using IPFS, data can be stored, verified, and processed locally, subsequently synchronized and shared with other IPFS nodes when a network connection is established.

Vendor lock-in occurs when a user is compelled to persist in using a product, such as a cloud computing service. This is due to the impracticality, high costs, legal constraints, or technical complexity associated with switching to another vendor.

IPFS mitigates vendor lock-in by granting users control over their data and infrastructure. This is facilitated through content addressing, which separates data from reliance on a singular location or infrastructure provider. Unlike conventional cloud vendors, IPFS allows the relocation of data storage without necessitating alterations to APIs and data management. Furthermore, being open-source, community-maintained, and modular, IPFS doesn’t mandate users to adhere to a specific subsystem. Instead, users can tailor IPFS to align with their preferred technologies, requirements, and values.

IPFS is designed to be compatible with existing web protocols, allowing it to be used alongside traditional web technologies.
Notably, the IPFS gateway has been developed to provide an HTTP-based service that allows IPFS-incompatible browsers, tools and software to access IPFS content.

For example, some browsers or tools like Curl or Wget don’t support IPFS natively and cannot access to IPFS content using canonical addressing like ipfs://{CID}/{optional path to resource}.

As such, there are multiple gateway types and gateway providers available so that applications of all kinds can interface with IPFS using HTTP, for instance Pinata.

IPFS is intended to create a more resilient and decentralized internet by providing a distributed and peer-to-peer alternative to traditional centralized file storage and sharing systems. It has gained attention for its potential to improve the efficiency and reliability of content distribution on the internet. Throughout this article, we delved into its fundamental mechanisms, highlighted its primary advantages, and emphasized its pivotal role in the creation of NFTs.

[ad_2]

Source link

By akohad

Related Post

Leave a Reply

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