Blockchain and InterPlanetary File System (IPFS)
Blockchain and InterPlanetary Files System(IPFS)
In this article, we will be going to talk about InterPlanetary File System (IPFS) and Blockchain technologies that will create a web that is distributed, immutable, and secure. This article is for people who would like to learn about IPFS and its integration with Blockchain.
The current web doesn’t impose any security measures by itself. It is up to the provider to think about the consumer’s security, which represents the centralized nature of the web. It also provides no guarantee that the content, which is accessed today will be available tomorrow. It means that the web is mutable.
HTTP is inefficient and expensive. There is only one node from where the data can be accessed. HTTP fetches a file from a single computer at a time, instead of getting pieces from multiple computers simultaneously.
Possible Solution
At its core, the web is just a very large data store. If this store was decentralized, immutable, and provided a way to verify the truthiness or source of data, then this could become a solution that can build a verifiable immutable web. IPFS and Blockchain technologies have these properties. Using them together to build a data storage system could become a solution.
InterPlanetary File System (IPFS)
The InterPlanetary File System (IPFS) is a peer-to-peer (P2P) distributed file system that seeks to connect all devices with the same system of files. IPFS is a content-addressed block storage format with content-addressed hyperlinks that allows for high throughput. This formes a data structure upon which one can build versioned file systems, blockchains, and even a permanent web. IPFS combines a distributed hash table, block exchange, and a self-certifying namespace.
Instead of using a location address, IPFS uses a representation of the content itself to address the content. The hash represents a root object. Instead of getting a response from a server, you gain access to the root object’s data. With HTTP you are asking what is at a certain location, whereas with IPFS you are asking where the certain file is.
Note: In the section that follows, we are not going to explain Blockchain in detail, because it is already covered here and here. However, we will be going to talk about Blockchain in terms of making the web that is distributed, immutable, and secure.
Blockchain
The blockchain doesn’t need centralized data storage for maintaining its data.
There are various blockchains with different goals, but these are the common elements:
Replicated ledger. The history of all transactions among nodes in a blockchain is securely stored.
Cryptography. Integrity and authenticity of all transactions shared among the blockchain nodes are supported with digital signatures and specialized data structures. Privacy of transactions is also supported with anonymous addresses for transactions.
Consensus. Transactions that are exchanged among the blockchain nodes need to be validated before adding to the existing blocks. The validation requires unanimity among the blockchain nodes.
P2P networking. All transactions are shared without centralized control over the web, i.e. the blockchain nodes are connected through a P2P network over the web, and not through the client-server model.
Blockchain also has some downsides. The blockchain ensures a strong degree of security for its chain, but the risk of managing private keys exists. Private keys are used in the blockchain to prove ownership of a certain item or data, but they can be lost or stolen.. Another issue is scalability. As the blockchain is immutable, it must maintain a continuously growing list of blocks. As transactions need to be broadcasted to blockchain nodes connected through a P2P network, the network could be easily congested.
Integration of IPFS with Blockchain
It is possible to address large amounts of data with IPFS and to place the immutable, permanent IPFS links into a blockchain transaction.
Blockchain Architecture
Blockchain stored the complete transaction details in the chain. While this data is immutable and replicated across multiple nodes, the size of data becomes a serious source of problems. Storing entire data instructions increases the byte size of the chain and affects the blockchain performance. It decreases replication speed and increases the computation cost.
Possible Solution for Blockchain Data Storing
Instead of storing the entire data, the data can be stored at a different location and an address pointer to that location, while the hash of the data can be stored in the chain.
These are the advantages of this approach:
- Byte size of the chain is kept to its minimum.
- The address pointer and data hash require fewer bytes than the data itself.
- A lightweight chain means that it can be quickly replicated across the network and consensus algorithms can easily work with them.
- Storing the hash of the data enables immutability by giving data verification advantages from the file hash.
This architecture can be divided into two parts. The first one deals with the storage of data in the IPFS network and indexing it in the blockchain. The second part deals with the retrieval of data from IPFS using the indexed hash from the blockchain.
Specification
The basic working implementation of this approach requires a blockchain and an IPFS daemon working on a network. A simple blockchain, a simple proof of work algorithm, and a consensus algorithm to resolve conflicts. The IPFS daemon can be installed on nodes and the daemon can be started to interact with it.
Indexing and Storing Data
The steps for indexing and storing data are as follows:
The file is encrypted using a private key. File data can be secured by the author using an encryption system. Since the stored files are open, if the author wants to restrict access to its content, it has to be encrypted.
Result file is hashed. IPFS produces an SHA-256 hash of the file. The file is stored in the network, and a hash is returned. This unique hash is used to identify and retrieve the file from the network. Returned file hash is saved in a transaction in the blockchain. A block is created periodically, which preserves the contents of the chain.
Retrieving Indexed Hash and Data
The steps for retrieving indexed hash and data are as follows:
Get file hash from the blockchain. To identify and retrieve a file from IPFS, the file hash is required. File hash is taken from the blockchain.
Get encrypted file from IPFS using file hash. A GET method for the file with the file hash can be requested to the IPFS network which will return the file. The name of the file will be its hash.
Decrypt a file using the private key. If the file was initially encrypted before saving, it has to be decrypted first before it is ready for use.
Conclusion
The proof of work consensus mechanisms have slowed transaction speed. This makes storing data or large files on the blockchain not feasible. The IPFS is a P2P distributed file system that seeks to connect all devices with the same system of files.
The drawback of the blockchain is that it can’t hold large-sized data. Large-sized data slows the cloning and storing process and hence slows the entire network. This has been fixed by introducing IPFS storage to store the data and pass on the immutable URLs pointing the data to the chain. The files are encrypted before storage and decrypted on retrieval by an authentic user.
In this article, we have seen the following:
- A possible solution for making the web decentralized, immutable, and secure.
- Basics of InterPlanetary File System (IPFS).
- Basics of blockchain in terms of making the web that is distributed, immutable, and secure.
- Integration of IPFS with Blockchain.
Credit: Nemanja Grubor
Blockchain Bridges
Blockchain Bridges
We have now reached a multi-chain market structure after years of research and development. Over 100 public blockchains are currently in use, and many of them have special uses, users, geographic distributions, security methods, and architectural trade-offs. Contrary to what some communities may think, the cosmos actually has an entropy tendency, and as a result, there will probably be more of these networks in the future. This kind of market structure makes interoperability between these many networks necessary. As a result of this realization by many developers, the number of blockchain bridges that aim to integrate the more dispersed environment has exploded in the past year. There are more than 40 separate bridge projects underway as of this writing.
Interoperability unlocks innovation
As individual ecosystems grow, they design their own original strengths, for example, better security, faster throughput, less expensive transactions, greater privacy, particular resource provisioning (e . g . storage, compute, bandwidth), and territorial developer & user communities. Bridges are essential because they allow users to permission for new platforms, protocols to interoperate with one another, and developers to collaborate on creating new products. More specifically, they allow :
Unlocking new features and use cases for users and developers
- Bridges give users and developers more choices. For example:
- Arbitrage SUSHI prices across DEXs on Optimism, Arbitrum, and Polygon
- Pay for storage on Arweave using Bitcoin
- Join a PartyBid for an NFT on Tezos
Greater productivity and utility for existing cryptoassets
Bridges enable existing crypto assets to travel to new places and do new things. For example:
- Sending DAI to Terra to buy a synthetic asset on Mirror or earn a yield on Anchor
- Sending a TopShot from Flow to Ethereum to use as collateral on NFTfi
- Using DOT and ATOM as collateral to take out a DAI loan on Maker
Greater product capabilities for existing protocols
Bridges expand the design space for what protocols could achieve. For example:
- Yearn vaults for yield farming on Solana and Avalanche
- Cross-chain shared order books for NFTs on Ethereum and Flow for Rarible Protocol
- Proof-of-Stake indices for Index Coop
Bridges
At an abstract level, one could define a bridge as a system that transfers information between two or more blockchains. In this context, “information” could refer to assets, contract calls, proofs, or state. There are several components to most bridge designs:
- Monitoring: There is usually an actor, either an “oracle”, “validator”, or “relayer”, that monitors the state on the source chain.
- Message passing/Relaying: After an actor picks up an event, it needs to transmit information from the source chain to the destination chain.
- Consensus: In some models, the consensus is required between the actors monitoring the source chain in order to relay that information to the destination chain.
- Signing: Actors need to cryptographically sign, either individually or as part of a threshold signature scheme, information sent to the destination chain.
It is important to note that any given bridge is a two-way communication channel that may have separate models in each channel and that this categorization doesn’t accurately represent hybrid models like Gravity, Interlay, and tBTC since they all have light clients in one direction and validators in another. In addition, one could roughly evaluate a bridge design according to the following factors:
- Security: Trust & liveness assumptions, tolerance for malicious actors, the safety of user funds, and reflexivity.
- Speed: Latency to complete a transaction, as well as finality guarantees. There is often a tradeoff between speed and security.
- Connectivity: Selections of destination chains for both users and developers, as well as different levels of difficulty for integrating an additional destination chain.
- Capital efficiency: Economics around capital required to secure the system and transaction costs to transfer assets.
- Statefulness: Ability to transfer specific assets, more complex state, and /or execute cross-chain contract calls.
Issues with Bridges
Building robust cross-chain bridges is an incredibly difficult problem in distributed systems. While there is a lot of activity in the space, there are still several unanswered questions:
- Finality & rollbacks: How do bridges account for block reorgs and time bandit attacks in chains with probabilistic finality? For example, what happens to a user who sent funds from Polkadot to Ethereum if either chain experiences a state rollback?
- NFT transfers & provenance: How do bridges preserve provenance for NFTs that are bridged across multiple chains? For example, if there is an NFT that is bought & sold across marketplaces on Ethereum, Flow, and Solana, how does the record of ownership account for all of those transactions and owners?
- Stress testing: How will the various bridge designs perform under times of chain congestion or protocol- & network-level attacks?
The future of blockchain bridges
While bridges unlock innovation for the blockchain ecosystem, they also pose serious risks if teams cut corners with research & development. The Poly Network hack has demonstrated the potential economic magnitude of vulnerabilities & attacks, and I expect this to get worse before it gets better. While it is a highly fragmented and competitive landscape for bridge builders, teams should remain disciplined in prioritizing security over time-to-market. While an ideal state would have been one homogeneous bridge for everything, it is likely that there is no single “best” bridge design and that different types of bridges will be best fit for specific applications (e.g. asset transfer, contract calls, minting tokens).
Furthermore, the best bridges will be the most secure, interconnected, fast, capital-efficient, cost-effective, and censorship-resistant. These are the properties that need to be maximized if we want to realize the vision of an “internet of blockchains”.
It is still early days and the optimal designs have likely not yet been discovered. There are several interesting directions for research & development across all bridge types:
- Decreasing costs of header verification: Block header verification for light clients is expensive and finding ways to decrease those costs could bring us closer to fully generalized and trustless interoperability. One interesting design could be to bridge to an L2 to decrease those costs. For example, implementing a Tendermint light client on zkSync.
- Moving from trusted to bonded models: While bonded validators are much less capital efficient, “social contracts” are a dangerous mechanism to secure billions of dollars of user funds. Additionally, fancy threshold signature schemes don’t meaningfully reduce trust in these systems; just because it’s a group of signers doesn’t remove the fact that it is still a trusted third party. Without collateralization, users are effectively handing over their assets to external custodians.
- Moving from bonded to insured models: Losing money is bad UX. While bonded validators & relayers disincentivize malicious behavior, protocols should take it one step further and reimburse users directly using slashed funds.
- Scaling liquidity for liquidity networks: These are arguably the fastest bridges for asset transfer, and there are interesting design trade-offs between trust and liquidity. For example, it is possible to enable liquidity networks to outsource capital provisioning with a bonded validator style model where the router can also be a threshold multisig with bonded liquidity.
- Bridge aggregation: While bridge usage will likely follow a power law for specific assets and corridors, aggregators like Li Finance could improve UX for both developers and end-users.
From the article of Dmitriy Berenzon
What is CBDC?
What is CBDC?
A CBDC abbreviated as Central Bank Digital Currency is the sovereign equivalent of private cryptocurrencies and digital assets like Bitcoin, Ethereum, Solana, and Ripple. It would be issued and controlled by a country’s Central Bank and used by people and businesses for retail payments, much like cash but in digital form. CBDCs will also be used for wholesale settlements in the interbank market.
In simple words, we can say that CBDC is a token on the blockchain and is issued by the central government by which people can do the day-to-day financial activity, Similar to that of fiat currency. For example, the Government of India will issue its own CBDC i.e., an Indian Rupee token similar to any other private Cryptocurrency like Bitcoin, Ethereum, Ripple, Solana, Polkadot, etc.
CBDC represents a new technology and approach for the issuance of central bank money, and can be characterized by the following:
Digital assets: CBDC is a digital asset, meaning that it is accounted for in a single ledger (distributed or not) that acts as the single source of truth.
Central bank-backed: CBDC represents a claim against the central bank, just as banknotes do.
Central bank controlled: The supply of CBDC is fully controlled and determined by the central bank.
There can be two types of CBDC:
Wholesale CBDC: CBDC that would be used to facilitate payments between banks and other entities that have accounts at the central bank itself.
Retail CBDC: CBDC is used for retail payments, for example between individuals and businesses, and is akin to digital banknotes.
Architecture:
Benefits of CBDC:
Cross Border Payments: A central bank digital currency (CBDC) can boost innovation in cross-border payments, making these transactions instantaneous and helping overcome key challenges relating to time zone and exchange rate differences
Enhance existing payments infrastructure: A central bank digital currency (CBDC) will Increase the speed and efficiency of payments while reducing costs and failure rates
Maintain control: Ensure Central Banks retain sovereignty over monetary policy and not allow alternative currencies to dominate the market.
According to the BIS, today some 80% of central banks are looking at CBDC, with the majority of them considering blockchain as the underlying technology. While many of these banks have expressed interest in both wholesale and retail use cases, most of the admittedly few actual experiments or pilots carried out to date have focused on wholesale. These include Project Ubin by the Monetary Authority of Singapore, Project Khokha by the South African Reserve Bank, China’s DC/EB, and Project Stella, a joint research project by the ECB and the Bank of Japan.
What is Substrate?
What is Substrate?
Substrate is a blockchain framework that is open-source. Substrate includes all of the essential components for constructing a distributed blockchain network. Database, Networking, Transaction Queue, and Consensus are just a few examples.
Although these layers are extensible, Substrate considers that the average blockchain developer is unconcerned about the implementation specifics of these key components. Substrate makes it as simple and flexible as possible to design a blockchain’s state transition function. Substrate runtime is the name given to this layer.
Substrate Components
We assume that you have a basic knowledge of Blockchain i.e, about blockchain nodes, its production, finalization, etc. So we will now see how Substrate works as a foundation for creating a blockchain. The Substrate framework’s initial claim to fame is that it is extensible. This means it makes as few assumptions as possible about how your blockchain is designed and tries to be as general as possible.
Database
The heart of a blockchain, as we’ve seen, is its shared ledger, which must be maintained and kept. Substrate makes no assumptions about the data in your blockchain’s content or structure. A modified Patricia Merkle tree (trie) is implemented on top of the underlying database layer, which employs simple key-value storage. This unique storage structure allows us to quickly determine whether or not an object is stored there. This is especially crucial for light clients, who will rely on storage proofs to deliver lightweight but trustworthy interactions with the blockchain network.
Networking
A peer-to-peer networking protocol must be established for a decentralized blockchain system to communicate. Libp2p is a modular peer-to-peer networking stack used by Substrate. Substrate-based blockchains can share transactions, blocks, peers, and other system vital details without the use of centralized servers thanks to this networking layer. Libp2p is unusual in that it makes no assumptions about your specific networking protocol, which is in accordance with Substrate’s philosophy. As a result, alternative transports can be implemented and used on top of a Substrate-based blockchain.
Transaction Queue
As previously stated, transactions are gathered and organized into blocks, which determine how the state of the blockchain changes. However, the order in which these transactions are completed might have an impact on the ledger’s final state. Substrate gives you complete control over transaction dependencies and queue management on your network. Substrate simply assumes a transaction has a weight and a set of prerequisite tags for creating dependency graphs. In the simplest situation, these dependence graphs are linear, but they can get more complex. Substrate takes care of all of the intricacies for you.
Consensus
Remember that a blockchain network can reach a consensus on updates to the chain in a variety of ways. Traditionally, these consensus engines have been inextricably linked to the rest of the blockchain. Substrate, on the other hand, has gone to great lengths to establish a consensus layer that can be easily altered during development. In fact, it was designed in such a way that when the chain went live, consensus could be hot-swapped! Multiple consensus engines, including standard Proof of Work (PoW), Aura (Authority Round), and Polkadot consensus, are built into Substrate. Polkadot consensus is unusual in that it isolates the block production process (BABE) from the block finalization process (GRANDPA).
Substrate Runtime
So far, we’ve covered all of the key blockchain components that Substrate offers. The substrate has made every attempt to be as general and extendable as possible, as you have seen. The modular runtime, on the other hand, is likely the most configurable aspect of Substrate. Substrate’s state transition function, which we discussed earlier, is the runtime.
Substrate thinks that the common blockchain developer doesn’t need to be concerned with the above-mentioned blockchain components. The implementation details are generally unimportant as long as the components have been battle-tested and are ready for production. The underlying blockchain logic that defines what is and is not acceptable for a network, on the other hand, is frequently crucial for any chain.
As a result, Substrate’s main goal is to make blockchain runtime development as simple and versatile as possible.
Substrate Runtime Module Library (SRML)
The runtime of a Substrate is separated into logical components known as runtime modules. These modules will be in charge of some components of the blockchain’s on-chain functionality. These modules can be thought of as “plug-ins” for your system. As a Substrate developer, you have complete control over whatever modules and features you choose to include in your chain.
The currency of the chain, for example, is managed by a module called “Balances.” There are other modules for decision-making and governance for the chain, such as “Collective,” “Democracy,” and “Elections.” There’s even a “Contracts” module that can convert any Substrate-based chain into a smart contract platform. When you develop on Substrate, you get these kinds of modules automatically.
However, Substrate’s modules are not the only ones available. Developers can easily create their own runtime modules, either as standalone logical components or by interacting directly with other runtime modules to create more complex logic. I believe that, in the long run, Substrate’s module structure will function similarly to a “app store,” where users can simply pick and choose whatever features they wish to include, and construct a distributed blockchain network with minimal technical knowledge!
Forkless Runtime Upgrades
If we consider the Substrate module ecosystem to be similar to an app store, we must also consider how we update our runtime. The substrate has made changing your runtime a first-class operation, whether it’s for bug patches, general enhancements to current modules, or even new features you wish to add to your blockchain.
Changes to your chain’s state transition function, on the other hand, affect the network’s consensus. If one node on your network has one version of your runtime logic and another has another, the two nodes will be unable to reach an agreement. They will have fundamental disagreements about the true state of the ledger, resulting in a fork, as we stated earlier. Irreconcilable forks are problematic because they weaken your network’s security by requiring only a small number of nodes to accurately construct and validate new blocks.
The substrate has addressed this problem by allowing the network to agree on the runtime logic! We can put the Substrate runtime code on the blockchain as part of the shared ledger using the Wasm binary format. This means that anyone running a node can check to see if their node has the most up-to-date logic. If it doesn’t, it will directly execute the on-chain Wasm! This means that your blockchain may be upgraded in real-time, on a live network, without forking!
To understand more in-depth about the basics of Substrate Codes you can visit here.